Re:FileKit: An open source end-to-end encrypted cloud storag...
by pvg on Thursday August 29, 2019 @10:18PM
(#20835458)
The issue of having to trust the server also applies in a lot of non-browser cases. For example, I have to trust the 1Password update server, or forego 1Password updates.
These are not quite the same kinds of trust - nearly every request to a compromised web app server is an opportunity to inject malicious code and malicious UI and compromise the clientside part of the app.
Compromising a software update server doesn't necessarily get you any of that - for instance, your 1Password client will presumably verify the authenticity of the update before it applies it.
Re:FileKit: An open source end-to-end encrypted cloud storag...
by goliatone on Thursday August 29, 2019 @08:26PM
(#20834949)
Re #2 There’s this [1] tc39 proposal.
You could also hack a solution using dynamic method names and Symbols.
[1] https://github.com/tc39/proposal-private-methods/blob/master...
Re:FileKit: An open source end-to-end encrypted cloud storag...
by csande17 on Thursday August 29, 2019 @11:15PM
(#20835693)
I don't think the private methods proposal will help with cryptography at all. The "security" it provides boils down to making it difficult for code outside the class to access the value, like you can already do with closures like this:
function makeCounter() {
var x = 0;
return function() { return ++x; };
}
It doesn't help at all with side-channel attacks, which are the main reason why it's hard to safely perform cryptographic operations in a just-in-time interpreted language like JavaScript. It also doesn't stop rogue scripts on the same page from pulling the user's passwords/keys right out of the password field, URL bar, localStorage, or wherever else your script gets them from.
It looks like the issues with browser-based cryptography from those two articles fall into three broad groups.
1. You have to trust the server.
2. The browsers don't do a good job of letting a site's JavaScript keep things secret from other things running in the browser.
3. If you implement cryptography in JavaScript, you are probably going to screw it up. There's a lot more to doing it right than just knowing to use AES and whatever the currently favored hash function is.
#1 is probably acceptable in a lot of cases, and #3 can probably be addressed by using the Webassembly version of libsodium.That leaves #2 as the apparently insurmountable issue.
Suppose the user was willing to create a separate Firefox or Chrome profile just for using my web-based app, and did not install any browser plug-ins under that profile, set its home page to my app page, and never used that profile to visit any other sites.
How close would that come to dealing with #2?