>DOMCrypt presentation at Mozilla All Hands

2011/04/11 — 4 Comments

>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.

Advertisements

4 responses to >DOMCrypt presentation at Mozilla All Hands

  1. 

    >It's good to see someone working on this, because it's clearly important.Item 3 seems like the most important, not least in order to get the APIs right.e.g. I'm not sure I really understand the addressbook/identity piece and what kind of applications/task flow you're envisaging.Where's the best place do discuss this in a little more detail?

  2. 

    >@David Illsley:You are correct. #3 is indeed the top issue. I should have reversed the order.The Addressbook API allows users to exchange "addressbook entries" (or public keys) via a metatag. I was trying to design the tiniest bit of functionality that allows for the exchange or credentials.I will put up a screencast demo very soon.I have just created a discussion group here: http://groups.google.com/group/domcrypt-discussCheers,David

  3. 

    >Could this also be used to replace (self-signed) HTTPS? My thinking is as follows. The first time you visit a site, it prompts the user to "install" the encryption. The site does the install by generating the needed keys and putting them into localStorage and also sending them to the server. The install needs to be done over a secure connection, of course, but that wouldn't be the case for future visits. In fact, it's exactly the same deal with the https-only flag, except here you have the advantage of not needing 3rd party verification services. (Which are a pain!)

  4. 

    >@Voracity:DOMCrypt is focused on DOM/web page functionality, however, I am sure your idea could be implemented. DOMCrypt is not using all of the APIs for proper SSL connections.Cheers,David

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