It is, they’re darkpatternmaxxing.

There used to be a time sites got punished if they treated searchbots differently..

Been there, done that, wrote the stub/mock and ended up with the better test. :)

False, opportunity theft is the most common form.

Better doors/windows/locks help the most, and help against both opportunistic and targeted.

And it also signals that you actually do want to improve, just a little bit of boy scout rule goes a long way.

Such a service will always be destroyed by the bell-ends who want to run spam or worse activities.

And not only cd. Gotta love 'git checkout -'

And maybe more importantly: security tools and researchers.

Your attempt has similarities to the idea behind Checking Sec-Fetch-Site. Implementing that header is the same amount of work. But this header is exactly meant for this purpose, and referer is haunted with problems.

So for officially intended protections, implementing this header and samesite cookies gets you a very long way without any complexity, assumptions, or tricks of old lore.

It could still be a security error, but only if all availability errors are for that project. But after triage, the outcome is almost always “user can hang own browser on input which isn’t likely”. And yes, it’s a pity I wrote ‘almost’, which means having to check 99% false alarms.

Yup, and I don’t care. I liked the brand better without the drama queen.

But sure, ironic and counterintuitive.