5 ms·
> Do you trust Dropbox to not send compromised JavaScript every time? If so, why not trust them with your keys in the first place? I don't trust Dropbox to do
by qntm 16y ago
> Do you trust Dropbox to not send compromised JavaScript every time? If so, why not trust them with your keys in the first place?
I don't trust Dropbox to do either of these things, but at least in theory I can examine the JavaScript each time they send it to me, whereas there is no way for me to inspect Dropbox's internal operations to make sure they aren't misusing my key.
The problem becomes mechanically verifying that a received chunk of client-side JavaScript is indeed the decryption routine that it claims to be. I think this is a solvable problem.
- pavpanchekha 16y agoActually, checking that two pieces of code are equivalent is undecideable: http://en.wikipedia.org/wiki/Lambda_calculus#Undecidability_of_equivalence http://en.wikipedia.org/wiki/Lambda_calculus#Undecidability_... So mechanically checking that Dropbox-supplied code is the decryption routine claimed is impossible.
- qntm 16y agoTrue. However, we don't need to be able to compare two arbitrary chunks of code. As long as our algorithm provides no false positives, I would settle for something as simple as a checksum.