For Knuth's sake: The GDPR is NOT about cookies! The older 'cookie directive' is also NOT about cookies! They're about a third party storing their data on your computer, or storing your personal data on their computers - no matter what technology is used.

Nothing in the GDPR stops websites from honoring "Do not track" and then _not asking_ if it's present. They don't have to ask if they don't track you! They don't have to ask for a technically necessary session cookie that appears after you actively log in!

Websites ask because they want to track you! A 'law targeting browsers' would not help because people would say no to cookies, and then websites would ask about some other way to track you. Because they want to track you.

Switched from Gmail to Fastmail about 10 years ago.

2-3 spam emails slip through every week, and sometimes a false positive happens when I sign up for something new. I don't see this as a huge problem, and I doubt Gmail is significantly better.

Pretty sure Zed won't let me pay for an editor without any "sign in" or LLM features?

The 'no to tracking' cookie doesn't need to be identifiable in any way.

Luckily, GDPR isn't about cookies, it's about processing personal information. Doesn't matter if you use cookies, localstorage, or carrier pigeon.

The older EU 'cookie directive' only mentions cookies as an example of storage in a footnote. The regulative is actually about any storage on the users computer.

Marketers would like you to believe that the stupid banners are about cookies. They're not - they're about processing your personal information.

This will give more resources to tenants that schedule more jobs.

If tenant A schedules 99 jobs and tenant B schedules 1 job, a "fair" algorithm would pick B's job either first or second, RANDOM() will not.

I'm assuming they disallow bot use in their TOS. So they can probably offer unlimited searches that you run yourself by typing in the terms.

For $10 their cost for someone constantly typing new searches is significantly negative. It's surprisingly expensive for them to do a search and doing 1 search every 30 seconds for 8 hours is ~3x more than the cap of their $5 tier. I'm not saying that's a reasonable usage case for me I'm just saying the limit on profitability occurs SIGNFICANTLY sooner than "as fast as you can type for a month".

Spam texts are not really a thing here in Norway, either.

I do get three to four phonecalls from spoofed UK numbers every month. I havn't picked up for a year or so, but last time I did, it was a fake "Microsoft Support" scam.

Taking my phone number out of gule sider fixed the Microsoft scam calls for me.

As I understand it, if you modify the xml, Keepass will silently export entries in the database once you load it (by providing the password).

Keepass will (by default) not ask for the password a second time before exporting - but you have to decrypt the database once before it can be exported.

So this is not a risk if your threat model is "attacker obtains a copy of my .kdbx", but it is a risk if your threat model is "attacker can modify .kdbx without me noticing, and can access my local computer or a mounted network disk to read the exported passwords".

The point is that the password manager application ought to allow a configuration change which affects document X's plaintext only after the master passphrase has been entered by the user for document X. It's not hard to implement that for configuration files and plugins in a multi-document setting, you just need to store suitable authorization secrets in the documents. In a single-document application it's more trivial, of course, you'd encrypt the configuration file and plugins with keys derived from the master passphrase or check their signatures.

It's actually less of a risk than I thought, because the configuration is on your local install of KeePass, not in the database file.

If an attacker can modify your local install, you've lost anyway....

You have to think about security as being layered. There is a huge difference between creating a mock copy of an application or injecting code into an existing binary, and toggling a setting in a human-readable XML configuration file. Most operating systems also monitor executables more carefully than document files.

My understanding is that the attacker doesn't need to inject code, they can simply take screenshots or recordings programmatically and when that shows the password manager all passwords are exposed.

> So this is not a risk if your threat model is "attacker obtains a copy of my .kdbx", but it is a risk if your threat model is "attacker can modify .kdbx without me noticing, and can access my local computer or a mounted network disk to read the exported passwords".

No, the threat model is "the attacker can modify config file", which for default installation also means "the attacker can modify the executable".

You can approximate something by defining the valid TokenTable keys as an enum, and using a mapped type for the actual TokenTable type.

There's some boilerplate in the definition, but it's fairly clean and non-repetitive. And easy to use in the "client code".

https://www.typescriptlang.org/play?#code/KYOwrgtgBAKg9ga1AS...

You can also write the array first, without using enum:

const tokens = ['parenOpen', 'bang', 'plus', 'minus'] as const;

type Token = typeof tokens[number];

type TokenTable<T> = Record<Token, T> // alias for { [key in Token]: T }

const isToken = (t: string): t is Token => tokens.includes(t);

const patterns: TokenTable<RegExp> = { bang: /\+/, // rest }

You put some real effort into the example. It's the opposite approach of how I did it, yet works just as well. Thanks!