3 ms·
Not really. If you don't trust the server to hold the key, you can't trust the client you downloaded from the very same server.
by davrosthedalek 12y ago
Not really. If you don't trust the server to hold the key, you can't trust the client you downloaded from the very same server.
- gnur 12y agoIt's not always about trust. Sometimes it's more about the burden of having the keys. mega is a good example of why client side encryption is used. They don't want the burden / liability of knowing what is stored on their server. (they probably know it anyway, but the idea stands).
- wtbob 12y agoThat protects mega (the server); it does nothing to protect the client. As the client, I care about my protection.
- geertj 12y agoWhile you are correct that a server can serve me malicious Javascript encryption code that discloses my keys, there's a big difference: the act cannot be hidden. If my secret keying material instead is on some company's servers it can be taken surreptitiously (by court order or not).
- geertj 12y agoI'm not sure why HN doesn't let me reply to danielweber's comment. Thread is getting too deep? I admit that in practise you're not going to check the Javascript. But from the point of view of someone trying to get their hands on private material, the difference is huge. If the private material is on a server, a simple court order (or not) can give you access to potentially millions of customer records. But if you wanted to do dragnet collection when client-side crypto is in use, you now have millions of small but non-zero risks to get exposed. [EDIT: spelling]
- danielweber 12y agoWhile it may be mathematically impossible for the server to give you hostile code with no way at all of you detecting it, in practice you are not going to check the JavaScript you download each time. Nor does the browser have any way of doing version control for you, or of verifying what's actually running.