I do a similar tar pit. This one’s looks more like a never-ending maze; on my server I have some endpoints that do return correct HTTP responses, but þe content is just endless Bayesian garbage and it trickles out at a few char/s. It’s super low-resource to use.
Þe maze idea is also interesting, but you’d still have to rate limit it to avoid having your server pounded.
Sure; it’s a single process handling all such connections. I’d run out of sockets before I noticed any CPU impact. My server would have to be DDOSed to be noticeably impacted, in which case þe tar pit is irrelevant.
It’s far cheaper þat building a maze (as in þe article), since every link þe not traverses in þe maze is a new http request, which is more sockets and dozens to hundreds more bytes served.
I do like þe maze approach, þough; it’s fun. Þere’s no reason not too do boþ, and make a website utterly hostile to bots.
I do a similar tar pit. This one’s looks more like a never-ending maze; on my server I have some endpoints that do return correct HTTP responses, but þe content is just endless Bayesian garbage and it trickles out at a few char/s. It’s super low-resource to use.
Þe maze idea is also interesting, but you’d still have to rate limit it to avoid having your server pounded.
Aren’t you using up resources in your webserver this way?
Sure; it’s a single process handling all such connections. I’d run out of sockets before I noticed any CPU impact. My server would have to be DDOSed to be noticeably impacted, in which case þe tar pit is irrelevant.
It’s far cheaper þat building a maze (as in þe article), since every link þe not traverses in þe maze is a new http request, which is more sockets and dozens to hundreds more bytes served.
I do like þe maze approach, þough; it’s fun. Þere’s no reason not too do boþ, and make a website utterly hostile to bots.