Hacker News Reader

Comment by blahbl4hblahtoo | Hacker News Reader

If you just expose your service as an API then you don't have to worry about users trusting code given to them by the site. Then use a native client app that doesn't suck to interact with the service...all of the encryption is done client side with all of the messages being encrypted end to end.

JavaScript encryption just isn't really valid in browsers...the browser runtime is to blame. Its funny that people have to all learn the same lessons over and over again...it's a worthwhile goal...keep at it, just try a different approach.

View on HN

Its [sic] funny that people have to all learn the same lessons over and over again

That pretty much defines what the field of computer security is. From DES to AES, we learned the same lesson: As things designed to be secure are put out in the real world, with sufficient enough time, they're broken. It's important not to make the same mistakes again and again, and that's nearly impossible to do with JS-Crypto since there are so many permutations of platform X on implementation (browser) Y. As long as the numbers of platforms is large and the numbers of browsers are large, having one implementation that works properly in all platforms isn't practical.

However, a specific implementation targeted at a specific browser/platform could be vetted provided the JS engine handles random numbers in a cryptographically sound manner. Ideally, the browsers would expose ways to call vetted cryptographic APIs directly via JS.

That's already happened w/ the crypto.getRandomNumber function, which openpgp.js uses/

That really doesn't change the equation. That's only if you can trust the client code...and it just isn't feasible with JS sent to you from a 3rd party.

pgp works because it transfers data and not code.

That sounds much more interesting. Solving key exchange and message transport in a friendly way, then using a native client has possibilities. I think that's the direction [Hemlis](https://heml.is/) is taking.

That could happen. The API is already there, in JSON over HTTP. One could gut all the UI logic and run it in a node program, or rewrite the client.

That's not a bad idea. Take the browser engine and embed it in your app...then never load code that isn't your own. That's not a web app...thats a native client.

Reply on news.ycombinator.com