5 ms·

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 do

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.

Procrastes 13y ago
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/ https://heml.is/) is taking.
mdip 13y ago
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.
- jaekwon 13y ago
  That's already happened w/ the crypto.getRandomNumber function, which openpgp.js uses/
  - blahbl4hblahtoo 13y ago
    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.
jaekwon 13y ago
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.
- blahbl4hblahtoo 13y ago
  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.

Procrastes 13y ago

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/ https://heml.is/) is taking.

mdip 13y ago

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.

jaekwon 13y ago
That's already happened w/ the crypto.getRandomNumber function, which openpgp.js uses/
- blahbl4hblahtoo 13y ago
  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.

jaekwon 13y ago

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.

blahbl4hblahtoo 13y ago
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.