Apparently, I have been summoned by the “7 things” internet meme… This is where you divulge 7 things that people may not know about you and tag 7 more people. I am wondering how I get paid for this. It is a ponzi scheme, right?

The details of my life are quite inconsequential.

1. My father was a relentlessly self-improving boulangerie owner from Belgium with low grade narcolepsy and a penchant for buggery. My father would womanize, he would drink, he would make outrageous claims like he invented the question mark. Some times he would accuse chestnuts of being lazy, the sort of general malaise that only the genius possess and the insane lament.

2. My mother was a fifteen year old French prostitute named Chloe with webbed feet.

3. My childhood was typical, summers in Rangoon, luge lessons. In the spring we’d make meat helmets. When I was insolent I was placed in a burlap bag and beaten with reeds, pretty standard really.

4. At the age of 12 I received my first scribe. At the age of fourteen, a Zoroastrian named Vilma ritualistically shaved my testicles. There really is nothing like a shorn scrotum, it’s breathtaking, I suggest you try it.

Uh, just kidding… Of Course, the previous points are a joke.

Here we go:

When I was five, my family moved to Germany so my dad could help with the post World War II occupation, you know. This was in 1977. (Wow, I am  old.) We lived in Augsburg for 3 years. I was quite aware of the Cold War at the age of 5.

I enrolled in my Junior year of college and never paid the tuition and never showed up to class, instead, I played guitar in a band that was nearly signed to a major record label. of course, these things just never turn out the way you want them to. My band played some pretty big shows opening for Blur once, and other indie bands such as Medicine, The Leaving Trains and Catherine. We recorded at the same studio as Smashing Pumpkins and occasionally hung out with some of them. Ahhh, hanging with Rock Stars at 20 years old… those Were the Days.

I saw the Orb in 1993 and renounced rock music for techno, starting a fledgling techno music group in Chicago. I DJ’d at some pretty huge Raves back in the day. Some of my music is on SoundCloud.

Back in 1995, Netscape went public, I finally set up a PPP account at Suba.net in Chicago. My boss at the time told me the “internet is a fad, the future is in the CD-ROM”. I quit my job and went to work at Northwestern University where they have had an internet connection since 1981. I taught myself HTML. I was into the web.

My wife and I eloped to Italy for a wedding in Florence. We spent a month in Italy, Croatia and Germany and probably spent as much money as the average bride spends on a dress. I HIGHLY recommend it.

I worked at Industrial Light and Magic for 18 months and that is all I can tell you about it, except that it felt more like working at IBM than a tech company on Tatooine (it WAS also a lot of fun).

My wife and I have 2 children, Cecilia – 5 and Henry – 1. Last year we moved back to the Chicago area, bought a place in the woods and are adjusting well to country living.

That about sums it up. I am supposed to tag 7 people now: @shorlander, @dao (is he on twitter?), @limi, @faaborg, @pastith, @ratcliffe_mike and @neonux

I have uploaded the latest DOMCrypt addon, which is version 0.4. It is not reviewed by the Addons team yet.
https://addons.mozilla.org/en-US/firefox/addon/domcrypt/versions/?page=1#version-0.4
I have updated it here as well:
http://mozilla.ddahl.com/domcrypt/extension/built/domcrypt.xpi

(note: The DOMCrypt extension, which is the bleeding edge code still uses ‘window.mozCipher’ as the window property name. The Firefox patch uses ‘window.mozCrypto’, the plan is to eventually merge this API into window.crypto )

I tried to make this API as simple as possible:

Encryption:

window.mozCipher.sym.encrypt(plainText, function callback(aCryptoObject){})

The resulting ‘CryptoObject’ has the following properties:

{
  cipherText: "...ENCRYPTED TEXT...",
  wrappedKey: "...A WRAPPED SYMMETRIC KEY...",
  iv:         "...KEY INITIALIZATION VECTOR...",
  pubKey:     "...A PUBLIC KEY..." // By default this pubKey
                                   // is the current user's public key,
                                   // which is used to wrap the symmetric key
                                   // so the actual key is never exposed to content.
}

Decryption:

window.mozCipher.sym.decrypt(aCryptoObject);

You can also pass in a public key to each method to wrap the key with another user’s key

Internally, a symmetric key is generated each time you run encrypt, it is wrapped with a public key to keep it safe and that cryptoObject is returned.

This is a first pass on an implementation – I tried to make it as simple as possible, with key safety the top priority.

A common use case for this API is localStorage encryption:

// web-based password manager app:)

var myWebPasswords = {gmail: "password", facebook: "password", twitter: "password"};

var jsonPasswords = JSON.stringify(myWebPasswords);

window.mozCipher.sym.encrypt(jsonPasswords, function callback(aCryptoObject){
  var jsonCryptPasswords = JSON.stringify(aCryptoObject);
  localStorage.setItem("jsonCryptPasswords", );
  delete myWebPasswords
});

// decrypt

var myWebPasswords;

var cryptoObj = JSON.parse(localStorage.getItem("jsonCryptPasswords"));

window.mozCipher.sym.decrypt(cryptoObj, function callback (aPlainText){
  myWebPasswords = JSON.parse(aPlainText);
});

This API is simple to use, and gives you a more secure way of using localStorage – or IndexDB, etc.

A really handy summary of the recent W3C Identity Conference held in Mountain View has been posted: Identity in the Browser Workshop Final Report (Draft)

The need for  “Identity” crypto APIs never made it into the DOMCrypt use cases page, until today. The point here is that I have maybe 2 uses cases for DOMCrypt that are important to me: easy symmetric and public key encryption of arbitrary data and the more secure, private messaging that will be made possible because of this. Others may have entirely different ideas that are just as valid. All of these ideas should be collected now as we are still in the design phase.

Of course, for me, the “Apps” are where its at. I am so much more excited about writing messaging apps using DOMCrypt than implementing DOMCrypt itself. Naturally, the API has to come first, work well and be accepted by browsers before the Apps can have a real impact.

A few developers have contacted me about how DOMCrypt works and are actively writing either extensions or web apps using DOMCrypt. This is super exciting.

If you also have an idea or are wondering how to get started playing with this API, please do not hesitate to contact me.I plan on blogging about the example code I have provided in the DOMCrypt content tests.

mozilla IRC: ddahl, twitter: @deezthugs, email: ddahl at mozilla dot com

If you think of additional use cases, I would like to hear them as well, or if you have a mozilla wiki account, please feel free to add them.

 

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.

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.

See: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest

DOMCrypt was discussed on the WHATWG mailing list last week, see: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-May/031741.html

I have summarized the discussion here: http://etherpad.mozilla.com:9000/DOMCrypt-discussion

Out of these discussions, I have updated the Firefox feature page: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI

A Use-cases page was created, see: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI/UseCases

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: http://domcrypt.org

The source code for the extension is here: https://github.com/daviddahl/domcrypt

The Mozilla bugs are here:

You can test the API by installing the extension hosted at domcrypt.org and addons.mozilla.org, and going to http://domcrypt.org

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.

>I am on my third project where I need to create a custom property on every web page in Firefox. Creating custom properties used to be somewhat of a hack, with mixed results, but today it is trivial.

For the release of Firefox 4, the content team created a new component, nsIDOMGlobalPropertyInitializer, which is a mouthful, but is a tasty morsel, I promise!

The basic procedure is this:

1. Create a JS Constructor and prototype with *some* XPCOM gunk

2. Make sure the prototype has an init() method

3. The object returned from the init method is the object lazily added to each web page

4. The init() method accepts an nsIDOMWindow argument if you need access to the window in your property

5. Name the new window property in your .manifest file

Here is an example:

let Cu = Components.utils;let Ci = Components.interfaces;let Cc = Components.classes;

Cu.import("resource://gre/modules/XPCOMUtils.jsm");Cu.import("resource://gre/modules/Services.jsm");

function DOMCryptAPI() {}

DOMCryptAPI.prototype = {

  classID: Components.ID("{3d92fb7f-be77-475c-992a-5235615f9189}"),

  QueryInterface: XPCOMUtils.generateQI([Ci.nsIDOMGlobalPropertyInitializer,                                         Ci.nsIObserver,]),

  init: function DA_init(aWindow) {

    let self = this;

    this.window = XPCNativeWrapper.unwrap(aWindow);

    let api = {

      // "pk": Public Key encryption namespace      pk: {        encrypt: self.encrypt.bind(self),        decrypt: self.promptDecrypt.bind(self),        sign: self.sign.bind(self),        verify: self.verify.bind(self),        generateKeypair: self.beginGenerateKeypair.bind(self),        getPublicKey: self.getPublicKey.bind(self)      },

      hash: {        SHA256: self.SHA256.bind(self)      },

      __exposedProps__: {        pk: "r",        hash: "r",      },    };

    return api;  },

  // Additional 'private' api methods  ...};

var NSGetFactory = XPCOMUtils.generateNSGetFactory([DOMCryptAPI]);

And, the contents of the manifest file:

component {3d92fb7f-be77-475c-992a-5235615f9189} DOMCrypt.jscontract @mozilla.org/domcrypt-api;1 {3d92fb7f-be77-475c-992a-5235615f9189}category JavaScript-global-property mozCipher @mozilla.org/domcrypt-api;1

“window.mozCipher” is the window property being added to each window

This does not currently work for content windows on Fennec/Firefox mobile, but works like a charm on Firefox 4.

Let me know if you have any questions as I have used this interface extensively.

Here is an mxr link to the console, which was written this way:

http://mxr.mozilla.org/mozilla-central/source/dom/base/ConsoleAPI.js?force=1

and the manifest: http://mxr.mozilla.org/mozilla-central/source/dom/base/ConsoleAPI.manifest?force=1

>I did a quick DOMCrypt presentation at the All Hands last week. It went well,  a lot of helpful and smart people showed up. I am thinking about all of the improvements that need to be made in the coming weeks to make DOMCrypt better.

There are 3 obvious things to do now:

1. Namespace the API to allow for future additional APIs

2. move all heavy-lifting work to a ChromeWorker

3. DOMCrypt needs a story – an understandable message – so that Web Developers and web users can understand the possibilities and the risks of not being in control of their data. Even talking about cryptography makes people’s eyes glaze over, so the move to simplify the nomenclature is essential.

The main story is a familiar one at Mozilla: User Control. Web users should be able to control who reads what they write online.  To everyone else, the message is a garbled stream of incoherent data. This should be the default mode in online communication – default and easy.

A fourth item is to figure out how to inter-operate with  existing Crypto standards. This is a very large undertaking, so I am not sure how it will play out yet. I have a lot of reading to do. I would like to have an elegant, “webby” toolkit that is easy to use and make available ASAP. Getting bogged down in standardization may work against this. Right now, I think supporting existing standards should be a long term goal which will be achieved via future APIs.

>DOMCrypt is a Firefox privacy extension I have been working on for some time. In this post I will attempt to explain what it is and why I am working on it in a somewhat non-technical manner.

What is DOMCrypt?

The core functionality is being able to take a bunch of text (or any data) and turn it into an unreadable blob via a password, right in any web page.

For instance, you can take the sentence: “Meet me in Lincoln Park by the beach at 2:00” and scramble it into something that looks like: iim08xKWVut3eqGubpq2jdCTanU7jV41q4UQKTJOoLD8y6sadUEm/8K9kpv+Wvq

The scrambled “version” of the sentence cannot be turned back into plain text unless you know the password required to convert it back.
This sentence can be sent to your contact, who alone can unscramble it and read the plain text.

The cool thing is that this kind of data scrambling – encryption – is pretty standard these days, in fact, you use this technology every time you visit a page that begins with https://.


The problem I am trying to solve is that the encryption tools in your browser are either not exposed to web pages for developers to use or the implementation (of, perhaps, an extension) is so complex, few users will ever use it.

Why DOMCrypt?

If you think about it, you realize that it is nearly impossible to communicate online without the content of the conversation recorded by a third party. Whether the purpose is ‘advertising’ or truly nefarious, you are stuck revealing your conversation to your internet provider, free email host, or social networking site. Perhaps that is not a problem to you, but to many it really is a bad situation.

The web has evolved into a network where users are tracked as web sites are traversed, their email and personal information is archived, collated, sliced, diced and indexed. Your data is not yours. This is about privacy and it is about ownership. Is privacy a relic? Is the ownership of your data important to you?

Privacy really needs to become the default configuration, a primary feature.

There is a lot of upheaval in the world right now. People all over the world need to be able to communicate privately, anonymously (or pseudo-anonymously) and quickly. With DOMCrypt, developers can build privacy-enhanced pages and applications which fully obscure at least the contents of these messages. The server that accepts these messages can be written so that there is virtually no identifiable data stored about the user.

I have created a Drumbeat project and the code is on Github.

As part of the project, I am building demo pages and web applications to demonstrate DOMCrypt in the wild. The first couple of demos show how basic encryption and an “addressbook” feature work:

http://mozilla.ddahl.com/domcrypt/demos/demo.html

http://mozilla.ddahl.com/domcrypt/demos/get-pub-key.html

I just put together a new demo that showcases a fully-working secure messaging application:

https://messages.domcrypt.org/

It is rough around the edges, but works and the source code is on Github.

>Console ideas

2011/02/22 — 2 Comments

>I recently filed bugs 635504 and 635502 in order to make Firefox’s Web Console customizable via the new Addon SDK and to create a global ‘Browser Console’ that lets you peek at all of the activity going on under the hood in Firefox.

The interesting exercise will be cannibalizing the Web Console to create a global console that displays all errors, css parse warnings, network activity and other events. The filtering interface will need even more options to cut through the density of messages. The cool part will be making commands – and perhaps APIs – that give you access to all of the services, observers, browser tabs and other Gecko bits currently running.

Live inspection of these objects will be a powerful tool for those interested in hacking on Firefox, but don’t know how to start.

The first customization of the Web Console we are planning is integration with Rob Campbell’s ‘Workspace’. I would like to see a console and workspace either side-by-side or be able to toggle between them, with the current console automatically providing a logging API.

I find the Workspace is already an essential tool when I start hacking something together – especially in the  ‘chrome’ context. The Workspace can save your snippets to files, so any commonly used tools and functions can be used as templates.

If you think of anything that would automate or make easier repeated tasks or techniques you use when hacking web apps or Firefox, let me know.

>For some time now I have been playing with the WeaveCrypto service – now a JavaScript module implemented on top of NSS via jsctypes. It is a pretty easy to use module – thanks in large part to the Weave (now Sync) team, Justin Dolske and many others.

I recently dove back into the code to try and distill down an easy to use API that can be attached as a property to any DOM Window.

The WeaveCrypto API was truncated because Sync started using a better encryption system (J-PAKE) for its purposes, so I had to dig through hg log to find the bits I needed:

http://hg.mozilla.org/mozilla-central/raw-file/d0c40fc38702/services/crypto/modules/WeaveCrypto.js

I took the old WeaveCrypto module and created an easy to use front-end component that sticks a ‘crypt’ property on each DOM Window.

My github repo is here: https://github.com/daviddahl/domcrypt 

A demo (with xpi link) page is here: http://mozilla.ddahl.com/domcrypt/demo.html

The 3 methods exposed (so far)  are generateKeyPair(), encrypt() and decrypt()

While I am not sure this is ‘production system’ ready, I am sure that these are the kinds of tools the users of the web need to build secure communications applications, toolkits and libraries.

Perhaps ‘Do Not Track’ can extend to ‘Do Not Datamine’?