valenterry
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.
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.
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.
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.
Yes of course. Just like you do for passkeys.
> Passkeys can in fact be backed by exactly this, i.e. a HMAC-only stateless implementation backed by a single password: https://github.com/lxgr/brainchain
No, not quite. It's written on there:
> "Login" with your passphrase, and you can create non-discoverable WebAuthN credentials (don't call them passkeys, but definitely be reminded of them) at ~all~ some websites supporting them (...)
That's the thing: with passwords, a website/app cannot prevent you from controlling the password yourself. With passkeys and attestation it can.
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.
And someone will be stuck not to do anything because they are unsatisfied with all languages. :-)
Erm, knowing and understanding how to use your database is a bread and butter skill of a backend engineer.
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.
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.
However I think there is a misunderstanding between being "deterministic" and "unambiguous". Even C is an ambiguous programming language" but it is "deterministic" in that it behaves in the same ambiguous/undefined way under the same conditions.
The same can be achieved with LLMs too. They are "more" ambiguous of course and if someone doesn't want that, then they have to resort to exactly what you just described. But that was not the point that I was making.
But it would be possible in theory.
Here's a very simple algorithm: you tell the other person (in English) literally what key they have to press next. So you can easily have them write all the java code you want in a deterministic and reproducible way.
And yes, maybe that doesn't seem much different from a programming language which... is the point no? But it's still natural English.
It's not an utopia. It will eventually happen and it will replace how react.js currently works. effect.website will probably be the foundation.
Yes. This is Germany we are talking here. I doubt any other country has higher (and more annoying) safety standards.
Now imagine you run two AIs (like ChatGPT) on your machine or on a server. You maybe even want them to cooperate on something. How do you do that? Right, you cannot, there is no standard, no interoperability, nothing.
This. It must be the problem of having grown up with it that makes people not realize it.
Software will need to operate like people in the real world. You can give your friend power of attorney, but usually you don't, you find a better way to get things done.