offline is necessary for secure browser crypto

[ghost]

There's been a lot written about how browser crypto is flawed from its very foundations, but I think with some tricks we can fix it. Offline first is a good start, but I think for crypto it doesn't go far enough. With the default way of building web apps, a crypto app could suddenly start serving malicious code without warning if the user is online because the browser by default will trust and run whatever code the server sends it. If law enforcement visits a website operator, they can force the website to deliver compromised code in a targeted or non-targeted capacity. Something like this scenario seems to have happened with lavabit, the email provider used by Edward Snowden.

The solution: don't allow websites to update! Turn your website into a brick! If you ever need to update your code, users should opt-in to receive updates and verify payloads through third-party out-of-band auditing that spans multiple international jurisdictions.

http://hyperboot.org/ - lib to brick a website with opt-in upgrades
https://keyboot.org/ - bricked website to store keypairs in-browser (going to rip out the slow RSA and do per-domain fast ECC keys soonish)

[michielbdejong]

Yes, exciting! Your work also triggered some interesting discussion on the "unhosted web apps" mailing list by the way.

[nolanlawson]

Here's a video of @substack's talk at DotJS. Good stuff; didn't realize you could abuse AppCache that way. :)

As for WebCrypto's flaws, @calvinmetcalf has been doing some interesting work to port Node.js crypto to the browser, and he conspicuously avoided WebCrypto:

• No, I didn't use the WebCrypto API
• Porting Node.js crypto to the browser, part 1
• Porting Node.js crypto to the browser, part 2
• Porting Node.js crypto to the browser, part 3