So there's a number of things in the spec that I would like to update that were assumed but aren't really appropriate for our use case. This idea of escalating bands is probably overcomplicating the matter. I think that we should set reasonable thresholds for different types of transgressions. For example, things that are clear indicators of attack, like certain user agents or certain paths, should immediately result in a seven-day ban with just a single request. I think that uh any further traffic from those sorts of band hosts should escalate the ban. So for example, sending three vulnerability scan probes, such as for environment variable files or git repos, uh should immediately cause a permanent ban. Uh the first request should cause a seven day ban. Subsequent request should cause the net block to be flagged as clearly malicious and permanently banned. The thresholds like a ten minute window with three malicious requests are way too low. It needs to be not a hair trigger because for example, violating a rate limit should only be like a temporary ban, maybe one hour or something. But repeated violations of the rate limit should escalate quickly. For example, if you're banned for an hour because you r'atere limited and then within a short time of the ban being lifted you violate the rate limit again that should double the band length or perhaps triple the band length. Um up to you know, if you're being banned for more than seven days it's just a permanent ban. Uh like clamp the clamp the maximum. Um Additionally, we need to abandon this idea of having to stop the container to edit the files. The files should be reread from disk when edited. I don't want the container to overwrite an admin edit. In fact, if the files are edited on disk, they should be re-read. The files on disk should represent the internal memory state of the application. So at any point if the application is shut down, the complete internal memory state of the application should be preserved, number one. And number two, if the files are edited on disk by an admin or new files are added, for example in the rule set directory, the files should be re-read and there should be live reload. Alternately, if we don't want to do that, then the uh hang up signal should be observed. But honestly, I think we should just watch the files for changes. Um what other things along these lines sort of administrative ergonomic uh changes could we make?
So there's a number of things in the spec that I would like to update that were assumed but aren't really appropriate for our use case. This idea of escalating bands is probably overcomplicating the matter. I think that we should set reasonable thresholds for different types of transgressions. For example, things that are clear indicators of attack, like certain user agents or certain paths, should immediately result in a seven-day ban with just a single request. I think that uh any further traffic from those sorts of band hosts should escalate the ban. So for example, sending three vulnerability scan probes, such as for environment variable files or git repos, uh should immediately cause a permanent ban. Uh the first request should cause a seven day ban. Subsequent request should cause the net block to be flagged as clearly malicious and permanently banned. The thresholds like a ten minute window with three malicious requests are way too low. It needs to be not a hair trigger because for example, violating a rate limit should only be like a temporary ban, maybe one hour or something. But repeated violations of the rate limit should escalate quickly. For example, if you're banned for an hour because you r'atere limited and then within a short time of the ban being lifted you violate the rate limit again that should double the band length or perhaps triple the band length. Um up to you know, if you're being banned for more than seven days it's just a permanent ban. Uh like clamp the clamp the maximum. Um Additionally, we need to abandon this idea of having to stop the container to edit the files. The files should be reread from disk when edited. I don't want the container to overwrite an admin edit. In fact, if the files are edited on disk, they should be re-read. The files on disk should represent the internal memory state of the application. So at any point if the application is shut down, the complete internal memory state of the application should be preserved, number one. And number two, if the files are edited on disk by an admin or new files are added, for example in the rule set directory, the files should be re-read and there should be live reload. Alternately, if we don't want to do that, then the uh hang up signal should be observed. But honestly, I think we should just watch the files for changes. Um what other things along these lines sort of administrative ergonomic uh changes could we make?
Recorded. Sorry this sat for two days without an answer.
This goes into the spec update, the folding unit of #6, together with issues 3, 4, 5 and the internet-ready directive in #7. That update:
replaces the spec's offence-counting ban model with yours. One request carrying a clear attack indicator, such as certain user agents or certain paths (probes for .env files or .git directories), bans for seven days. Further requests from that netblock mark it malicious and ban it permanently. A rate-limit violation gets a short ban of about an hour. A repeat soon after that ban lifts doubles or triples the length, and anything past seven days becomes a permanent ban.
makes the files on disk match the program's memory at all times, so a shutdown loses nothing. The program watches its files, re-reads any file an admin edits or adds (including in the rules directory) and never overwrites an admin's edit. This replaces the 2026-09-21 rule in #1 that state is loaded once at startup.
answers your closing question on this issue with a list of further proposals for easier administration, for you to pick from.
The repo is paused under the 2026-09-22 priority ruling. The unit runs when the repo resumes, and its PR closes this issue.
Model: opus-5-5
Recorded. Sorry this sat for two days without an answer.
This goes into the spec update, the folding unit of https://git.eeqj.de/sneak/smallwebwaf/issues/6, together with issues 3, 4, 5 and the internet-ready directive in https://git.eeqj.de/sneak/smallwebwaf/issues/7. That update:
- replaces the spec's offence-counting ban model with yours. One request carrying a clear attack indicator, such as certain user agents or certain paths (probes for `.env` files or `.git` directories), bans for seven days. Further requests from that netblock mark it malicious and ban it permanently. A rate-limit violation gets a short ban of about an hour. A repeat soon after that ban lifts doubles or triples the length, and anything past seven days becomes a permanent ban.
- makes the files on disk match the program's memory at all times, so a shutdown loses nothing. The program watches its files, re-reads any file an admin edits or adds (including in the rules directory) and never overwrites an admin's edit. This replaces the 2026-09-21 rule in https://git.eeqj.de/sneak/smallwebwaf/issues/1 that state is loaded once at startup.
- answers your closing question on this issue with a list of further proposals for easier administration, for you to pick from.
The repo is paused under the 2026-09-22 priority ruling. The unit runs when the repo resumes, and its PR closes this issue.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
So there's a number of things in the spec that I would like to update that were assumed but aren't really appropriate for our use case. This idea of escalating bands is probably overcomplicating the matter. I think that we should set reasonable thresholds for different types of transgressions. For example, things that are clear indicators of attack, like certain user agents or certain paths, should immediately result in a seven-day ban with just a single request. I think that uh any further traffic from those sorts of band hosts should escalate the ban. So for example, sending three vulnerability scan probes, such as for environment variable files or git repos, uh should immediately cause a permanent ban. Uh the first request should cause a seven day ban. Subsequent request should cause the net block to be flagged as clearly malicious and permanently banned. The thresholds like a ten minute window with three malicious requests are way too low. It needs to be not a hair trigger because for example, violating a rate limit should only be like a temporary ban, maybe one hour or something. But repeated violations of the rate limit should escalate quickly. For example, if you're banned for an hour because you r'atere limited and then within a short time of the ban being lifted you violate the rate limit again that should double the band length or perhaps triple the band length. Um up to you know, if you're being banned for more than seven days it's just a permanent ban. Uh like clamp the clamp the maximum. Um Additionally, we need to abandon this idea of having to stop the container to edit the files. The files should be reread from disk when edited. I don't want the container to overwrite an admin edit. In fact, if the files are edited on disk, they should be re-read. The files on disk should represent the internal memory state of the application. So at any point if the application is shut down, the complete internal memory state of the application should be preserved, number one. And number two, if the files are edited on disk by an admin or new files are added, for example in the rule set directory, the files should be re-read and there should be live reload. Alternately, if we don't want to do that, then the uh hang up signal should be observed. But honestly, I think we should just watch the files for changes. Um what other things along these lines sort of administrative ergonomic uh changes could we make?
Recorded. Sorry this sat for two days without an answer.
This goes into the spec update, the folding unit of #6, together with issues 3, 4, 5 and the internet-ready directive in #7. That update:
.envfiles or.gitdirectories), bans for seven days. Further requests from that netblock mark it malicious and ban it permanently. A rate-limit violation gets a short ban of about an hour. A repeat soon after that ban lifts doubles or triples the length, and anything past seven days becomes a permanent ban.The repo is paused under the 2026-09-22 priority ruling. The unit runs when the repo resumes, and its PR closes this issue.
Model: opus-5-5
Your closing question is answered with five proposals and a recommendation in #10.
Model: opus-5-5
clawbot referenced this issue2026-09-25 10:34:38 +02:00