valenterry

Right. That's why I think that the client syncing (all) credentials is just what I don't want/like and there must be a server, since a compromised client can obviously not be trusted to doing any rate-limiting.

And the server also needs to inform about usages, since otherwise a compromised client could just extract everything slowly over time.

Does that make sense?

Otherwise, basically just one compromised client means that suddenly all my credentials need to be considered stolen and have to be changed everywhere.

I wish there was a password manager with a different focus.

In the way where there would be a server (selfhosted) that has the passwords and is well protected. Then, on the server, I can configure access to the secrets on my clients and — and that is important — restrict the number of secrets that can be accessed per time. And on each client I want to be told if secrets got accessed by another client.

Because, optimally I would use passkeys and other means of authentication, except for initial auth. But if my client gets compromised I don't want it to be able to access and exfiltrate all secrets at once. That is basically the worst case scenario.

I don't understand why it's not common in password managers to have different categories of how important a secret is and better control/transparency to detect compromised clients and contain the impact.

And in-transparent pricing and this annoying dude that asks you once in a while if everything is okay, usually before the renewal.

Scala has dependant types (though inferior than Idris ones) and has the whole jvm ecosystem.

> Ideally, sure, but the reality is just that some entities are not only reputationally, but also legally required to bear the liability for account takeovers.

Seems like an absolutely rare edge case to me. Or maybe even just a misunderstanding. I doubt there is a law that says that. If anything, I could imagine a law saying that a company has to take "sufficient precautions".

But even if what you say were to be true - that's not something to solve with tech. That means the law should be changed.

Hm, I disagree. I prefer if the user has the freedom to choose how they want to do things. At the cost of some users choosing the wrong way and then getting problems. It's a question of balance, but when I look at recent tech/internet history, I tend to not want to give central authorities any more power than they already have.

> This is emphatically not fundamental to LLMs! Yes, the next token is selected randomly; but "randomly" could mean "chosen using an RNG with a fixed seed."

This. Thanks for saying that, because now I don't need to read the article, since if the author doesn't even get that, I'm not interested in the rest.

It's still in the standard. They could remove it, but they don't, so from my perspective it's just like how Google wasn't evil. Until they decided otherwise.

It should be noted that that is not an inherential advantage of passkeys over passwords. It is possible to achieve the same with passwords, e.g. by using a hash-cascade.

Then you should write assembly only. Like `MOV`, `ADD`... can't really get simpler than that.

Problem is, that makes every small part of the program simple, but it increases the number of parts (and/or their interaction). And ultimately, if you need to understand the whole thing it's suddenly much harder.

Surely you can write the same behaviour in "clever" (when did that become a negative attribute?) or "good" way in assembly. You are correct. But that's a different matter.

By that definition you will be stuck on the first language you love.

And someone will be stuck not to do anything because they are unsatisfied with all languages. :-)

> Shameless plug: learn your tool. Don’t approach Postgresql/Mssql/whathaveyousql like you’re a backend engineer.

Erm, knowing and understanding how to use your database is a bread and butter skill of a backend engineer.

Google isn't even good at engineering great software.

They have some good people working on some good projects. If you look at the relation between software-quality of their average product and number of developers they have... yeah I don't know. Maybe hiring tons of new-grads that are good at leetcode and then forcing them to use golang... is not what actually makes high quality software.

I could believe that they are good at doing research though.

> Static types, algebraic data types, making illegal states unrepresentable: the functional programming tradition has developed extraordinary tools for reasoning about programs

Looks like the term "functional programming" has been watered down so much that now it is as useful as OOP: not at all.

Look, what matters is pure functional programming. It's about referential transparency, which means managing effects and reason about code in a similar way you can do with math. Static typing is very nice but orthogonal, ADT and making illegal states unrepresentable are good things, but all orthogonal.