Archives For api

DOMCrypt round up

2011/06/13 — 3 Comments

While I work on the spec for DOMCrypt, I want to make sure to keep the latest information about the status of this API fresh.

For the uninitiated, DOMCrypt is a browser window API I have been working on that makes using public key and symmetric crypto as well as hashing easy and fast for web developers.  The current implementation is a Firefox add-on as well as a patch for Firefox.

First and foremost, a WebKit bug was filed to implement the DOMCrypt API! This is great news. Both Adam Barth and Jarred Nichols have jumped in to write the code.

Secondly, I have created a proper WebIDL document to describe the API:

The mailing list archives for the 3 lists I requested feedback and criticism from are here:

The consensus seems to be that this is a good idea – and a good place to start for a *high-level* browser-based crypto API. Some of the changes that should be made are:

  • Fold this API into the existing window.crypto property to avoid confusion
  • Removed the ‘addressbook’ sub-API as it adds too much undefined complexity (for now, anyway – I hope to revisit this concept in a separate spec)
  • Add an algorithm property to each sub-API to allow for forward migration to better, faster crypto
  • Add an HMAC sub-API to round out the API

All of this has been reflected in the spec.

I have attempted to aggregate most of the discussion into this etherpad (may need some updating):

As far as the Gecko implementation is concerned, Brian Smith has been giving me a lot of pointers on what will be a better implementation, starting with a new set of APIs to more easily handle the interfacing with NSS, see bug 662674

I would love to collect more feedback on this API, please do not hesitate to join in on the discussion.

It seems like the time is right for this to gain steam as we see the effect of not having these  tools  – in what seems like daily personal data breaches on the web. I think an API like DOMCrypt will help spur new communications tools that have security, privacy and user control built in from the ground up.


There has been so much written and discussed online and off about privacy, user control and identity lately. This dovetails nicely with the draft spec for DOMCrypt as a proposed Crypto API for web browsers.


DOMCrypt was discussed on the WHATWG mailing list last week, see:

I have summarized the discussion here:

Out of these discussions, I have updated the Firefox feature page:

A Use-cases page was created, see:

For anyone unfamiliar with DOMCrypt, this proposal in a nutshell says:

Privacy and user control on the web is of utter importance. Tracking, unauthorized user data aggregation and personal information breaches are becoming so commonplace you see a new headline almost daily. (It seems).

We need crypto APIs in browsers to allow developers to create more secure communications tools and web applications that don’t have to implicitly trust the server.

The DOMCrypt API is a good start, and more feedback and discussion will really help round out how all of this should work – as well as how it can work in any browser that will support such an API.

This API will provide each web browser window with a ‘cipher’ property[1] that facilitates:

  • asymmetric encryption key pair generation
  • public key encryption
  • public key decryption
  • symmetric encryption
  • signature generation
  • signature verification
  • hashing
  • easy public key discovery via meta tags or an ‘addressbookentry’ tag

[1] There is a bit of discussion around adding this API to window.navigator or consolidation within window.crypto

I have created a Firefox extension that implements most of the above, and am working on an experimental patch that integrates this API into Firefox.

The project originated in an extension I wrote, the home page is here:

The source code for the extension is here:

The Mozilla bugs are here:

You can test the API by installing the extension hosted at and, and going to

The API:

window.cipher = {
 // Public Key API
 pk: {
   set algorithm(algorithm){ },
   get algorithm(){ },

  // Generate a keypair and then execute the callback function
  generateKeypair: function ( function callback( aPublicKey ) { } ) {  },

  // encrypt a plainText
  encrypt: function ( plainText, function callback (cipherMessageObject) ) {  } ) {  },

  // decrypt a cipherMessage
  decrypt: function ( cipherMessageObject, function callback ( plainText ) { } ) {  },

  // sign a message
  sign: function ( plainText, function callback ( signature ) { } ) {  },

  // verify a signature
  verify: function ( signature, plainText, function callback ( boolean ) { } ) {  },

  // get the JSON cipherAddressbook
  get addressbook() {},

  // make changes to the addressbook
  saveAddressbook: function (JSONObject, function callback ( addresssbook ) { }) {  }

  // Symmetric Crypto API
  sym: {
  get algorithm(),
  set algorithm(algorithm),

  // create a new symmetric key
  generateKey: function (function callback ( key ){ }) {  },

  // encrypt some data
  encrypt: function (plainText, key, function callback( cipherText ){ }) {  },

  // decrypt some data
  decrypt: function (cipherText, key, function callback( plainText ) { }) {  },

  // hashing
  hash: {
    SHA256: function (function callback (hash){}) {  }

I am in the process of posting this proposed spec for review by the W3C webapps list and TC39. Your feedback and / or help with this effort will be greatly appreciated.

>With the Firefox UI/UX team starting to crank out design ideas for “Places” ( a Mozilla internal name for bookmarks and history) in Firefox 3.7 and 4.0, it’s high time the Places team revamped the query API.

Alex Faaborg has posted some initial UI concepts here:

I have started to think about how to make an elegant API to do the heavy lifting of querying the Places database for bookmarks, history and related hierarchies. The current Places query API is not simple to use, and we want this to be simple and easily extensible by extension authors, as well as a drop in api for Jetpack.

The bug for this work is here:

One of our non-goals is to make a snap in replacement for the current API. We get to focus on the new features, like “browsing” your bookmarks and history in content-space, as well as accessing bookmarks and history via the “awesomebar”.

I have posted the beginning stages of this work to the wiki, here, the Firefox “project page” is here. We are in a stage of thinking about and sketching what this simple, elegant API might look like, and we would love to get feedback and ideas from our colleagues and the Mozilla community. The Places 3.7 meta bug is here: