talkin

> Not that I think that this is LinkedIn's fault

It is, they’re darkpatternmaxxing.

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

Yes, that’s a good thing. That alg:none might be easy in tests is not a good reason for a weak mode in the real code and spec.

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

> Criminals don't just rob random houses

False, opportunity theft is the most common form.

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

It costs tokens, so it helps the business model, so it’s not a bug but a feature.

It’s also a weird argument. You can only spend your money once, and the affected employees also chose to work for a bell-end like Altman (or Zuck, or Musk)

Fixing easy cases makes the list shorter, so enables more focus on harder cases.

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

> for some reason the industry stubbornly refuses to solve the "cron job as a service" problem for end-users, whether on the web or in the OS.

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

> cd -: The classic channel-flipper. Perfect for toggling back and forth.

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

There will always be early adopters.

And maybe more importantly: security tools and researchers.

Or even an autoincrement int primary key internally. Depending on your scale and env etc, but still fits enough use cases.

Most regex usage actually doesnt require near infinite backtracking, so limited unless opted in wouldn’t be that weird.

“Intuitive!”

NO. Please don’t spread wrong solutions.

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.

No. The Regex DoS class of bugs is about infinite backtracking or looping inside the regex engine. Completely isolated component, just hogging CPU inside the regex engine. It may also have ‘DoS’ in its name, but there’s no relation to network (D)DoS attacks.

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.