2 ms·

Your issue applies to any system that can pull executable code from the web and dynamically execute it, including almost every scripting language. You could pul

by yid 15y ago

Your issue applies to any system that can pull executable code from the web and dynamically execute it, including almost every scripting language. You could pull the password before it hits the browser plugin. There is no remedy to this under the circumstances -- not open source, not peer review, not SSL, not distributed systems. You'd have to use a signed binary whose source you had examined yourself, at the least. So even the distributed FOSS argument is snake oil. BTW, I'm not trying to imply that these guys have solved the problem -- there are numerous problems, as you pointed out.

michaelchisari 15y ago
You could pull the password, but you couldn't pull the private key from the browser (or plugin). Encryption/decryption is done in the browser, and the host server acts purely as a data store, incapable of doing anything with that (encrypted) data. The trust question then gets moved from the host to the browser. Have you read the link I posted about how you could approach encryption at the browser level? Far from not solving the situation, I think they fall into the category of "half-way encryption is worse than no encryption at all", and they don't seem to understand the social concept of trust. As Jon Callas says, "Encryption is not magic pixie dust that makes everything okay."