this post was submitted on 11 Jul 2023
115 points (100.0% liked)
/kbin meta
639 readers
1 users here now
Magazine dedicated to discussions about the kbin itself. Provide feedback, ask questions, suggest improvements, and engage in conversations related to the platform organization, policies, features, and community dynamics. ---- * Roadmap 2023 * m/kbinDevlog * m/kbinDesign
founded 1 year ago
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Umm what?
I remember people doing tests and other variations of words featuring “bot” went through no problem, even changing the spelling of KBin was enough to get in.
I’m gonna have to call BS on their excuse.
That assumes they were using an expression based filter in the webserver config itself. If they were extracting user agent strings containing the word "bot" from their webserver logs and adding them to a static list of user agents to deny (particularly if it's an external file referenced by the config that strings can be easily dumped into), it's a plausible explanation. I can especially see this happening if they did a blind sort by log volume and only inserted the 20 biggest results or somesuch.
Even if this was the case, was someone in a position to observe that one of those strings contained "kbin"? Yes. Was it possible they still didn't notice? Yes, especially if shell pipelines are involved. Was it possible for someone to notice but assume that this wasn't the kbin software itself, but a third-party tool that someone else wrote? Also yes. Still possible that all of this is bullshit? Still yes!
Full disclosure: I've worked in the webserver and webapp adjacent spaces for a long time, and I have a lot of appreciation for how much damage one person's stupid change without peer review can do in massive production environments. :) I am admittedly biased toward applying Hanlon's razor in these situations.
If they were doing that, others with bot in the name would have been caught, no?
Yet the people who tested it said that wasn’t the case.
Like I said, a blind sort by volume of the top n user agents in their logs containing the word bot would be enough to do it. Drop the output of that sort into a text file or a hash table, then create a user agent filter in the nginx config that blocks the specific strings seen in that file.
It is very much the sort of thing that a single admin can do by accident, and the exact sort of problem I would expect to see with rapidly growing instances operated by a very small number of tech enthusiasts.