[sdevlin]

The web is not a secure medium for this kind of application.*

This is because all the encryption features they tout depend implicitly on content (HTML and JavaScript) the server sends you every time you use the application. Because you receive this content anew on every usage, there's no way to verify what you're getting. Today it might be fine, but tomorrow it might contain a key logger or subtle cryptographic flaws.

You also can't depend on the community for help verifying this content, because it can be distributed selectively. The mass of users might get benign content while interesting targets get backdoored software.

* It might be safe to distribute something like this as an installable sandboxed web application. I'm actually not 100% certain. But the no-install-just-browse-to-this-url model is definitely insecure.

[orthecreedence]

The best way is a browser extension, but even that has its pitfalls (firefox especially since there's no real sandboxing).

It's never a good idea to do crypto over a website.

[sdevlin]

> The best way is a browser extension, but even that has its pitfalls (firefox especially since there's no real sandboxing).

I would be greatly interested if you could expand on some of the pitfalls of browser extensions and how they differ among browsers. Thanks in advance!

[orthecreedence]

I think the general pitfalls of a browser extension is that you're essentially trusting that the browser, which is acting almost as an OS in terms of separating the memory contents of different extensions, to work correctly. The idea is if you have an extension doing crypto, an extension that is syncing data with google has no way of reading the data from the crypto extension. You also have to make sure the same applies for websites as well...extensions should be able to grab data from sites, but not vice versa. Without this kind of perfect separation, your crypto extension is really just a sitting duck and none of the data in it is safe.

As far as how they differ among browsers, Chrome (and I suppose Opera, now as well) does a good job sandboxing one extension from another, and from stopping websites gaining access to running extensions. Is it perfect? I can't really answer that.

One problem with Chrome extensions is that unless you want your users to have to download the .crx file, and drag and drop it into their browser, you have to use the Chrome webstore. This is especially retarded because in order to upload your extension to the Chrome webstore, they either need your private key you signed the extension with, or they generate a private key for you. This means that your private key is not private and extension signing is a complete joke. So if you're releasing an extension for the security-literate, it makes sense to create a .crx file, sign it yourself with your own PGP key, and offer it as a separate download that they have to drag+drop into Chrome. The chrome webstore is not a secure means of distribution.

Firefox, on the other hand, is more forgiving with installations but has no real sandboxing. This means it's possible for one extension to read another's data. Plans to introduce threading (and I think as a consequence of threading, sandboxing as well) are in the works, but it's still going to be a while until Firefox gives extensions the same protections Chrome does.

Really, if you can, it's best to do crypto in a native app where the sandboxing is done for you by the operating system and you don't have to rely on a browser. Node-webkit is a great way to do this since it merges the two worlds nicely (at least for desktop).

[sdevlin]

Thanks for the great reply!

I didn't realize the Chrome web store requires your private key. That's insane.

[thinkling]

Yes, I think those risks can be eliminated with some elbow grease since there's no need to load this app off a live server.

Instead, one would download a specific version as a tarball with a verifiable checksum that indicates the source is equivalent to the version audited by the community on GitHub. The app is then loaded & run locally.

In addition, you could control network access if you wrap it in its own OS-native custom browser app and use a firewall that controls outgoing connections. (Like LittleSnitch on OS X.) That is, create a thin shell around WebKit uniquely for use with this web app, and control its network access.

(I think the two measures are redundant, but hey, if you're going to be paranoid...)