I hadn't yet seen that particular article but I'm very familiar with those arguments. Thanks for the link!
I agree with them that building a crypto library in JS that can be trusted regardless of the security properties of the web application is impossible (content-controlled code, runtime malleability).
However, I don't think those points mean that building an application that as a whole has good security properties and uses JS crypto is impossible. If the entire application code is delivered on first load and code is never dynamically loaded, one should be able to audit and trust that complete application. That'd mean no ads, no google analytics, no CDNs, etc.
The next bit is reliable delivery. SSL is definitely needed. Because static code is all delivered on first load, an interested third party could download it at any time and see that it matches the audited code. The host would be caught if it attempted any attack that wasn't narrowly targeted.
And that's why it's better than just SSL. If the host receives the plaintext, there's zero chance of catching them.
Their points about graceful degradation and CSPRNGs are irrelevant; I'm only interested in targeting modern browsers with window.crypto.getRandomValues.
It isn't clear that you are properly taking into account the fact that a browser (also known as a user-friendly Remote Code Execution Engine) is an especially hostile environment.
I agree with them that building a crypto library in JS that can be trusted regardless of the security properties of the web application is impossible (content-controlled code, runtime malleability).
However, I don't think those points mean that building an application that as a whole has good security properties and uses JS crypto is impossible. If the entire application code is delivered on first load and code is never dynamically loaded, one should be able to audit and trust that complete application. That'd mean no ads, no google analytics, no CDNs, etc.
The next bit is reliable delivery. SSL is definitely needed. Because static code is all delivered on first load, an interested third party could download it at any time and see that it matches the audited code. The host would be caught if it attempted any attack that wasn't narrowly targeted.
And that's why it's better than just SSL. If the host receives the plaintext, there's zero chance of catching them.
Their points about graceful degradation and CSPRNGs are irrelevant; I'm only interested in targeting modern browsers with window.crypto.getRandomValues.