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?
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?