[dfabulich]

What is the threat model for PGP in JS? Like, is there an Alice, Bob, Carol, Eve story under which PGP in JS makes sense?

The canonical example that IMO doesn't make sense is when Alice and Bob want to communicate privately using Eve as an webmail provider who wants to snoop in on the communications. Alice and Bob can't just trust Eve to provide a copy of OpenPGPjs in a <script> tag on EveMail.com, because then they're trusting Eve to provide a legitimate PGP implementation, trusting Eve not to log their keystrokes in JS, etc.

I can understand OpenPGPjs as a server-side library in Node (though I suspect it would be safer to run a battle-hardened library like GPG with node FFI).

But, in client-side web code, how could this ever make sense?

[dane-pgp]

One user story is that Alice uses Eve's webmail, and Bob uses PGP and mutt on his laptop. Before Eve's webmail supported PGP in JS, Bob had to send his emails to Alice unencrypted (and unsigned), which meant his mail provider could read the plaintext (even if he trusted that mail provider to always require a TLS connection when sending to Eve's servers).

From Alice's point of view, she is just using webmail as she always has, except now she has the assurance that no one (other than Eve) can spoof Bob's identity, and that Bob's mail server isn't reading the messages she sends him (unless Eve is deliberately leaking the plaintext somehow despite sending Bob the encrypted version).

Long term it would be nice if the W3C's SRI standard was extended to allow offline signing of JavaScript files:

https://github.com/w3c/webappsec/issues/449

and for browsers to prompt you whether you wanted to run a new (offline signed, maybe independently audited) version of those files.

[emj]

> [Alice knows] no one (other than Eve) can spoof Bob's identity

If Carol or Chuck can spoof Eves "identity" they can spoof Bobs identity. This can be done in a multitude of technical or social ways.

Is it better to have this than nothing? The problem is that you have to trust your whole infrastructure if you want to do this kind of client side encrypting.

[dane-pgp]

If your threat model says that Eve's webmail servers can be spoofed, then Alice can't use webmail at all, or possibly any websites. At that point, the security of PGP in JS is pretty much irrelevant.

[emj]

I think that is one of the most obvious things that can happen, but no it only affects JS PGP that is integrated on a site you use. PGP in JS is still relevant because it makes it easier to download, verify and execute Javascript "anywhere", not as an integrated solution served by a third party. Sadly.

[dmos62]

I've been looking for gmail alternatives and this is my conclusion. Protonmail plays the part of the secure and private email provider, but, technologically, can't provide that. The only concrete thing their users have going is the superior legal environment of Switzerland. A less-than-concrete comforter is that if we believe that the people behind Protonmail believe in privacy, we'll tend to think they're more likely to try to protect ours if push comes to shove. This makes me look for alternatives.

[bartbutler]

So, that's a conclusion but no reasoning behind it, therefore it's impossible to evaluate critically.

[jlgaddis]

Apparently you missed the reasoning. ProtonMail has the capability to access either the plaintext and/or private keys.

(FYI: It is customary here on HN to disclose any affiliations when commenting.)

[johannes1234321]

One could have PGPjs in a webextensions in the browser and use it to encrypt/decrypt/sign/verify contents in forms.

One would of course still need a protection against key logging etc. (eventually the web extension has relevant matter only in a pop-up?)

[crispyporkbites]

Subresource integrity means you could trust Eve in some cases. Also if Eve provides a script tag from a trusted CDN it could work. You would have to check it every time though.

What might help is a browser extension that tracks changes and allows you to “lock” into a version of a website.

[e12e]

Technically Sri only reduces the amount of trusted data you need to keep around; you'd need an index.html that loads gpg.js and a js client that talks to a server (eg: jmap or a bespoke jsonapi that allows getting/sending mail).

This is pretty much what browser extensions do; bottle up some hypertext resources, signed and versioned.

You still have three obvious threats: local superuser can read application memory etc; your local user can read your memory and any browser compromise/bug can likely read your browser/session data.

The real question is if the browser sandbox is ever likely to be good enough that you don't have to worry about a font file from a compromised website about kittens reading your email in another tab.