How is that different from mutual TLS authentication?
Edit: It seems like OPAQUE just initiates mutual TLS authentication after the TLS session has already been negotiated with PKI. So it basically just allows websites to design their own login page instead of the one designed by the web browser.
I just replied to the other person's comment.
While Linux itself isn't proprietary, it supports loading proprietary firmware/microcode blobs and running on proprietary hardware. Thus, part of the Linux hardware/software stack is proprietary.
I'm surprised that other people are surprised that for-profit companies constantly try to increase their profits; such companies only contribute to FOSS when that's more profitable than the alternative. The Linux kernel, AMDGPU, Steam, etc only exist because some part of the software/hardware stack is proprietary (which becomes a more attractive product as the FOSS portion of the stack improves).
I'm definitely not justifying the "rug-pulling", but people need to stop supporting projects with no potential for long-term profitability unless those projects can survive without any support from for-profit companies. Anything else is destined to fail.
It's a nightmare to search for anything about GUID Partition Tables (GPT) now.
I'd love yearly Debian releases instead of just every 2 years.
Free (As in beer and speech!)
Do you live in a utopia where you get as much beer as you want without having to pay for it, or do you live in a dystopia where you have to pay to be able to speak your mind and only in limited quantities?
Thank you for interjecting.
The data block would be modified but the signature of that block can’t be recomputed without the key used to sign it
Isn't that also true of an encrypted checksum, though? For some plaintext block q there is a checksum r, but the attacker can only see and modify the encrypted q (Q) and encrypted r (R). How any change to Q would modify q (and R to r) can't be known without knowing the encryption key, but the attacker would need to know that in order to keep q and r consistent.
I'm not a cryptographer (so maybe this is wrong), but my understanding is that although it's possible to modify the cipher text, how those changes modify the plaintext are very difficult (or impossible) to predict. That can still be an attack vector if the attacker knows the structure of the plaintext (or just want to break something), but since the checksum is also encrypted, the chances that both the original file and checksum could be kept consistent after cipher text modification is basically zero.
In exchange, FF uses Google search by default. So they're also getting direct value from the deal.
Giving permission by saying yes to a "would you mind" question is the hill I die on. Usually I say "I would not mind" but if I'm feeling frisky I'll say no and watch their brain melt.