> 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.

That doesn't explain lack of such functionality at the OS/platform level. It technically exists on Linux and Windows, but is heavily optimized towards sysadmin use, and essentially hidden from regular users on the "normie UI surface". Most people don't even realize their computers could do things on a timer.

(And on Android, AFAIK there's exactly nothing at all. There's not even common support for any kind of basic automation; only recent exception is Samsung. From third-party apps, there's always been Tasker - very powerful, but the UX almost makes you want to learn to write Android apps instead.)

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

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

The '-' shortcut is weird. In 'git commit -F -', the '-' is actually /dev/stdin.

`-` is the traditional shell way to refer to stdin/stdout (as with your git commit example) but also the traditional way to refer to the last directory you were in (as with git checkout/switch).

You would never pipe the output of a command to `cd` so the `-` shortcut couldn't be helpful to cd as-is. So rather than invent yet another shortcut to memorize for `cd` they reused the existing one which otherwise would be redundant, which I appreciate at least.

But git is simply being consistent with the shell to further reduce the cognitive complexity of reusing shell commands you're used to in analogous git contexts.

- is a pretty standard idiom for using stdin/stdout instead of a named file that you can find in many commands. I don't think it conflicts with the cd/checkout usage though as there the argument normally does not refer to a file so having - mean stdin/stdout doesn't make sense.

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.

It's not a wrong solution. It's been commonly used since forever, tens of years before the sec-fetch-site header existed, and it stops CSRF. Sec-fetch-site is not supported in old browsers, so relying on that is unsafe without any fallbacks.

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.

Backup/restore tends too look less important until it isn’t. ;)

Interferes with the business model. ;)