Hacker News new | ask | show | jobs
by bpolverini 3889 days ago
Bingo.
1 comments

Say you attempt to do this all in JavaScript; you've still got to deliver the page (the encryption code, really) to the user securely; otherwise, I can modify it s.t. when it gets a blob from the server and decrypts it on the client, that decrypted value is also sent off to a shady spot. You still need to get your app from you to your user securely, and how do you do that?

It's the core problem really: how do you distribute your public key? How do you make sure Joe user gets the right public key? Today, we have the CA infrastructure, which admittedly isn't great, but… what would you do differently? (And the big problem is that it needs to work for average Joe.)

The one thing you can do with such a system is to make it harder to compromise the code and get away with it. Any gossip system, public ledger, etc. (including "the blockchain", but you don't actually need something that power-hungry) can enforce that my copy of the JS is the same as everyone else's copy of the JS.

Right now it's easy to get in a network position between a single person and Gmail, without anyone else knowing, especially if you're a government, which is why a valid .google.com cert is such a valuable target. Getting in a position to compromise everyone's* copy of Gmail is much more involved, and if you pull it off, it's instantly visible to the entire world.

http://hyperboot.org/ solves some of these issues
Couldn't you have a browser plugin that would verify your js is being served up from the correct source?
Subresource integrity (sort of) solves this.

http://githubengineering.com/subresource-integrity/