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: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest#Browser_Window_property_WebIDL

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): http://etherpad.mozilla.com:9000/DOMCrypt-discussion

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.

Advertisements

3 responses to DOMCrypt round up

  1. 
    Jesper Kristensen 2011/06/14 at 16:49

    I do not understand the purpose of this API.

    First a specific detail: The verify function does not seem to accept a public key. What key will it be verified against? Your own? It does not seem like it would be super interesting to verify a message from yourself.

    Generally, I do not understand what use cases there could be for this API given its private key per domain hidden within the browser. Why should the website JS not have access to the private key? Why should a web page not be able to use multiple keys at the same time? With these restriction this crypto API seems quite handicapped, and I cannot see any reasons for doing so. I am sure there are some thoughts behind doing this, I just cannot find it in your description.

    I also saw in a note on an Etherpad that the user would be prompted with a dialog when the website tries to use the API. If true, that just seems stupid to me. As the keys are for the website, it seems like there is nothing the user needs to accept, except the same kind of prompt you can choose to see when a website tries to set a cookie.

    • 

      Jesper:

      Good catch. I must have omitted the public key while editing the wiki. The original implementation is here for reference: https://github.com/daviddahl/domcrypt/blob/master/extension/domcrypt/components/domcrypt.js#L323
      As far as what this API is for, i think it is quite obvious. Messaging and communication is largely moving to the web – we need an API like this for keeping private conversations private and data used online firmly in control of users.

      The keypair per domain is in line with what is done with locaStorage to keep data domain specific and compartmentalized. The etherpad needs to be cleaned up a bit, as that is an old conjecture when it comes to dialogs and allowing host use of keys. Sorry about that, I will be updating it this week.

      • 
        Jesper Kristensen 2011/06/14 at 19:28

        Ok, but it just seems to me like uses within messaging and communication would be quite limited by not allowing the private key to move around. For example you would not be able to make something like Firefox Sync with it as far as I can tell.

        You cannot just compare it to localStorage. With localStorage, you (the web page) can still get your data out of it and put it somewhere else.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s