commit d8282f8067e8ace850cd57a56bff80d3951cc0b8
Author: James Halliday
Date: Thu Nov 27 18:54:26 2014 -0800

offline decentralized single sign-on in the browser

Recently, browsers have just begun to implement web cryptography. This means that browsers are now capable of the same kind of passwordless decentralized authentication schemes we've had server-side with ssh and tls asymmetric keys for decades.

Imagine if you could just generate a key and sign messages with that key, proving your identity to other users and backend services without the need for a password or even creating an account with yet another web server! We can have the ease of use of signing in with twitter or facebook without any centralized servers and very minimal setup from the end user's perspective.

Even better, this authentication system can work offline. In fact, the system must work offline to be fully secure.

appcache manifesto

By default, web pages can decide to send you whatever javascript and html payload it wants. This payload is probably what you want, at least at first, but consider what might happen if those asymmetric keys are used for commerce or for private communications. Suddenly, the webmaster could easily decide to serve a different payload, perhaps in a targetted manner, that copies private keys to third parties or performs malicious operations. Even if the webmaster is an upstanding person, a government agent could show up at any time with a court order forcing the webmaster to serve up a different payload for some users.

Imagine if whenever you ran the ssh command, your computer fetched the latest version of the ssh binary from and then executed it. This would be completely unacceptable for server programs, and browser apps that handle confidental keys and data should be no different!

Luckily, there is another relatively new feature in the browser that can protect against rogue server updates: the appcache manifest. A page can set a manifest file with:

<html manifest="page.appcache">

and then the browser will load a cache policy from page.appcache. The appcache file can be used to make some documents available offline, but can also be used to prevent the browser from fetching updates to documents. If the max-age header on the appcache file itself is set far enough in the future, the appcache file itself can be made permanent so that the server operator can't update this file either. In the future, the service worker API will provide enough hooks to do the same thing, but browser support is not widespread yet.


Upgrading an application should be possible too without going into the bowels of the browser to clear the appcache. This is where hyperboot comes in to give us opt-in application upgrades for end-users. More security-minded users might even want to check with external auditing systems before upgrading.


With a versioning system in place, we can now start implementing an offline single sign-on system that exposes the web crypto methods securely without exposing private keys to random websites.

There are another few nifty tricks with the service worker API that can give us realtime communication between tabs and iframes that works completely offline.

To give this new system a try, first open in a modern browser and generate a key.

Next open up in a new window or tab and paste into the text box. In the window, approve the request. Now from, you can sign messages with your private key!

Update: if gives cross-domain errors in your browser, try

There is still plenty to do and some unanswered questions about different threat models and how best to prevent replay attacks and domain isolation, but this proof of concept should be good enough to at least start people thinking about decentralized approaches to single sign-on and the changing role of servers and webapps as browser APIs become more capable.


git clone