Why is the list of discussion topics so short
on each page, at about 30 lines long?
My fingers and interest levels would like more per page.
Any reason it cant be more longer-er?
Comments
H&F looks bad because it has so many pinned Announcements clogging the first sub-page.
On a more general level, we are at the mercy of the Vanilla software.
30 lines is considered good for usability. Just thank your lucky stars that Vanilla wasn't designed last week by the grew-up-on-mobile-phones generation who don't understand proper screens, let alone how to use them.
Just spotted this - it's about performance, also because we occasionally get hammered by Russian bots (and ne'er-do-wells), and limiting the amount of data traffic significantly mitigates the impact.
Maybe we could apply a geoblock and / or implement a WAF?digitalscream said:Just spotted this - it's about performance, also because we occasionally get hammered by Russian bots (and ne'er-do-wells), and limiting the amount of data traffic significantly mitigates the impact.
I don't intend to limit the site geographically - I'm absolutely fine with Russian/Chinese/etc people using the site (in fact, there's at least one Russian member I'm rather keen to stay here). The bots that have attacked here have been from all over the globe, I only mentioned Russia because there are a couple of bots that crop up from there, and they occasionally change their signature, which means if I'm not around to catch it the site gets completely overrun.topdog91 said:Maybe we could apply a geoblock and / or implement a WAF?digitalscream said:Just spotted this - it's about performance, also because we occasionally get hammered by Russian bots (and ne'er-do-wells), and limiting the amount of data traffic significantly mitigates the impact.
The worst ones actually tend to come from within Europe and the US, so geo-blocking doesn't help there. They've also historically been very specifically targeted at this site, so a WAF-like approach wouldn't help because it would incur too many false-positives. Then there are the replay attacks, which need a more sophisticated toolkit to deal with.
I have a plan for this, it just can't be done with the current setup; Vanilla and PHP simply aren't capable of dealing with it properly. The new approach will automatically detect and stop pretty much any conceivable DoS attack request that isn't already taken care of at a lower networking level before it can affect any other services, at sub-millisecond cost.