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?
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.
You could also hack a solution using dynamic method names and Symbols.
[1] https://github.com/tc39/proposal-private-methods/blob/master...
function makeCounter() {
var x = 0;
return function() { return ++x; };
}
What do you think of doing JavaScript Crypto in a browser extension? An extension runs code in the browser without persistent trust of a server (at least in the traditional webapp way; you have to persistently trust the extension update server, extension authors, chrome update server, etc). You could do things like quickly, interactively encrypt chunks of text with a symmetric key. Presumably you'd use an extension UI to enter your keys, to avoid keylogging.
I think it would be illuminating to have a small suite of well-implemented cryptographic primitives, curated by a well-known expert, installed and ready to use on any string in the browser.
(BTW why don't we see more random chunks of cyphertext everywhere? It would seem to me a good channel, to use a combination of public forums to transfer short bursts of cyphertext. Where are the encrypted Twitter broadcasts??)
It only contains public keys and encrypted DEKs (data encryption keys); see this image: https://docs.tanker.io/filekit/latest/going-further/file-enc...
The file content should therefore only be accessible by holders of private keys for which the file was encrypted.
My understanding from the Apple/FBI fiasco is that it's an open question whether the US government is legally able to compel you to write and deliver custom code to your clients. But any local judge can issue you a warrant to hand over encrypted customer data that you're holding the key to.
But IANAL, maybe my take on that is overly simplistic.
https://wicg.github.io/webpackage/draft-yasskin-http-origin-...
What's still missing, I think, is a way for a publisher to tell a browser "Only run new code from this domain after checking that the user is happy to upgrade". That would put the "web app" on roughly the same security footing as a desktop application with a built-in update system.
You can have a trusted client and an untrusted server.
People have done lots of things with browser cryptography, that's true. But none of what they've done addresses or mitigates the central flaw of browser javascript cryptography, which is that to use it, you have to continuously and durably trust the server. If you're doing that, you might as well just do the cryptography serverside.