3 ms·
I have often seen claims that doing any kind of crypto in (browser) javascript is dangerous. Does this fall into that trap? How can I safely share the URL to
by no_protocol 10y ago
I have often seen claims that doing any kind of crypto in (browser) javascript is dangerous. Does this fall into that trap?
How can I safely share the URL to someone without already using an established encrypted communication method?
Is the encryption key stored in my browser history?
- anarcat 10y agoyes. you can't. and yes.
- gry 10y agoWhile the ideas and implementation are neat, this suffers from the chicken and egg problem[1]. You have to trust server's resources are not tampered with. Adding an event binding to tamper or siphon data before it's encrypted is simple. [1] https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/ https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...
- habitue 10y agoThe reason crypto in the browser is dangerous is because the crypto algorithms come from the server (they aren't built into the browser) so you have to verify them every time you go to the site to know they're doing everything properly. They could easily change them to no ops for you at the request of the NSA or whatever and you wouldn't know. So on the basis of that, I don't think this project avoids that problem
- DenisM 10y agoiOS silently installs updates too all apps from the App Store. There is no meaningful distinction between Javascript being served from the server and an App being served from the App Store.
- teddyh 10y agoYes. Yes they do, and I agree – there is no meaningful distinction. https://www.gnu.org/proprietary/proprietary-back-doors.en.html https://www.gnu.org/proprietary/proprietary-back-doors.en.ht...
- habitue 10y agoI agree 100%. This means both processes are insecure, though probably it's a matter of degrees, since you at least have the apple approval process filtering out blatant fuckery