[read]

You conflated two things.

Yes, having full source code is a sufficient condition for security. But you also implied that the hypothetical browser crypto primitives would allow one to do anything they want with the decrypted data, which might be too loose of an assumption.

For example, you could make the browser crypto primitives work so that you can only display unencrypted data (or a private key) but not be allowed to ship them off to servers.

The key idea is that you are still in control of the browser core, and that core has more control over the code shipped by the server. So you can make that core stricter than Javascript.

For example, about the problem of "other dom elements mucking with your dom elements that control the code" you can make the browser disallow this.

If I'm missing something, it's something related to these primitives. Can anyone help figure those out?

What exactly is theoretically impossible about browser crypto?

[IgorPartola]

Sure, if you want to break JS the language. JS doesn't have a concept of "here have a variable with data inside of it but you cannot touch it". Ask yourself: "what does 'display' unencrypted data mean?"You are describing a different system entirely from what an HTML renderer + JavasScript engine can do.

[pcwalton]

> JS doesn't have a concept of "here have a variable with data inside of it but you cannot touch it".

Actually, it does: closures (and WeakMap in ES6 has similar properties). They're pretty foolproof for information hiding, if used properly. (But this is irrelevant to tptacek's point about the security of crypto in JS, of course.)

[IgorPartola]

I don't think this is what the grandparent is envisioning. Also closures are great until you are able to replace the code that produces them, or read straight from the DOM at the place where you mail client is displaying the decrypted data.