4 ms·
Haven't read through the WebCrypto standard, but it's hard to create a real barrier between a server process and a client process on the web. In essence, any g
by javajosh 10y ago
Haven't read through the WebCrypto standard, but it's hard to create a real barrier between a server process and a client process on the web. In essence, any good crypto UI would have to happen outside of the client process, so that the server cannot intercept your input. (This is my objection to well-meaning companies that say "Hey, we can't even read your stuff, it's encrypted on the client" because, if you have auto-update, or if you ccan inject code into the client, that privacy guarantee can be revoked at any time.)
- jdormit 10y ago> if you have auto-update, or if you can inject code into the client, that privacy guarantee can be revoked at any time Anytime you use software built by someone other than you, any guarantee can be revoked at any time - the distributor can put whatever they want into the software! When a distributor makes claims about the privacy/security of a product, at some point you either trust them and take them at their word, or you don't - in which case, it doesn't matter what they say. Unless the product is open-source and self-hosted, that is.
- nine_k 10y agoIf the binary you are using is signed, and the signature is well-known via a side channel, you can at least make sure you're running the same binary. If the binary was built from a known source, and the build is reproducible, you can even be sure that the binary really represent the code in question; bugging a compiler so that it injects a malicious payload and keeps a crypto signature the same is a bit hard. (But the whole "trusting trust" chain applies.)
- jdormit 10y agoI'm with you there - I was more talking about the trust that needs to exist that the (official) binary distributor really is following through on their claims about privacy or security.
- deleted 10y ago[deleted]