A “bridge” crypto API

In working on the Web Crypto API specification, the valuable feedback and criticism keeps going back to the main pitfall: DOM malleability. The many attack surfaces in each web page makes handing over crypto keys and crypto primitives quite dangerous. As the W3 working group approaches this API we have this issue in mind, but, the API(s) we want to deliver are not going to solve the DOM-is-dangerous problem. Luckily, browser vendors are working on this – and have been – for years, and the work continues.

Firefox OS will introduce signed “privileged” and “certified” web apps that by default have very strict CSP applied to them. No eval(), no remote scripts or styles – the app is pretty well sandboxed against the most common attacks. These apps are signed and verified before installation and update. Let’s hope these kinds of approaches will help make web apps more “trustworthy”:)

So, how can we use crypto in web pages and not expose anything like keys or actual crypto functions or properties to the DOM? What does that look like? After thinking about the use case for this: web-based messaging, digital signatures for code and document verification – among others, I came up with what I am calling a ‘bridge’ API, I have named it “nulltxt”.

It has one method: window.navigator.bridge.getCipherObject()

This function creates a DOMRequest object, which you can attach event handlers to: “success” and “error”.

To generate a keypair, you pass a config object:

{type: "keygen", format: "DER_BASE64"}

into “getCipherObject”:

var request = window.navigator.bridge.getCipherObject({type: "keygen",format: "DER_BASE64"});
request.onsuccess = function (){ */ this.result.publicKey is our key /* };
request.onerror = function (error){};

Once your keypair is generated, the success callback is executed, handing you a public key and an ID you’ll need to decrypt or sign with that particular key. Multiple keys can be generated per origin.

To encrypt data, you call the same function with a different config object:

{ type: "write",
  format: "DER_BASE64",
  recipientName: "drzhivago",
  publicKey: A_PUBLIC_KEY,
  keyID: 7635263572 
}

This operation opens a special writing widget in the browser chrome where you can safely write plain text outside of the DOM:

Write some plain text, then click the encrypt button. The browser encrypts the data and returns it to your success event handler. The encrypted JSON blob is now available to send to the server where it can be received by Alice.

The result object looks like:

{
  "content": "yeGwdhLSs8qKDywerhs7pchNzxIpmtRGuBf59zMHegR/+urU20RbGxmHEvrx5yxmcEk8j9yPYHJLRKH6SJlEcDR4TKFzWNYLsMdoAxFi7AecN74MP2s0udvmg4vU944hYFo/F3fh2E9hnBF6xsdoRtCdkiNBLTRINCdDv3dgxLEe1UgdeXpbsIljgHc8svaD/lYik2rV+UojHk0yk9NFzv2tCu8wb58kzZluuo10qyqrX1X/rLpu2ZVlk/Ik+MbM7HxK1cSBL5kqUdNU/tx9qqVZVLzcAZz2ZDr2l0wRGKwoJ3f41QrwN8SGCRvMtpPEl1PdcYtdpTg4atAbNZ7T3cJhybtrYW64Yu7d9coguFQg2TQFU8hyIiWdFhY7XqOwR71KNgkHQr+ET/dRpV6TmBlN5IiUMgKq7achpOjkyJEBCfEURRpV71ViEo+37dT1SqIzxhlNY8yDn2gPhcC/DHk4eXi5axFkg4OyhxD9Q7hW7oW+1K/pzjYm2M+yCTtguQ9xikYouiiYbC3oFKMO9F6unfmDHJKc/XwWI9nsuYwSVSqPPZ8tj91pI/SB/ng8UyCojPrUO/jJ3cHjsWccY2XDg5ryVYVAmNWQQ9UEsTT8WrwyJ04i9/FEEYvVznyHlYB3z9diKDW35j7EZKPJQi7uYQVcdB3e2NMve2JPrxxwmebBLrHv4hpfaKmS8NcWpvJYp5r5U1iVLnwIpH98wEsHSrhyBKwBq1bf7s+Lvz9Hx8XuME4zbC6SN4j00QIx4eU3yuKnsa2LGj7b8UQ0GrtNwiRWKwF+qaH15f5rUEUN/9bwdljUVkXNbRg0s1Jde8z/OWevnS/B/AX760fPRxVz6QtEcKCSKZd5AqiVnqSTSzJmvY2izmweHb0uUde7PMsY3aYhNU9eNpA7p2Wmvd+YbSQjMNgnaqB9I+XwNwVZymjhQzar91FZtFSvw4YERA/zUIPFVgrEwdnOnp0t0ORyVOo1QZnvyPMwVddfWpN68aJCVK5dYGyI1uL8CzcBjZqgRjuKSQgt9JfhZJakvdXXPyCq3y5N8cbZZeQvpK8VcRCFHk6fRGrt4vAVSU6dgNewEoj51j+RsH0OOgcuCyJJ7BZgP4mHrrQWfLelnMU=",
  "pubKey": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8p4gH/RlmICUyCJop4AfvHvIkQjMWhUI4keK22MDVyNrDWSektxxX+VN5hLQzmNU/4jTCBBx2gICYcw0DGiw5HGBHp3e0KCmhcc48s3tLwf1TUuhdCEj1v+Oq+Z0FhVEEUF+GYpMBLQvy2HGlPUHbOZsYamKUspMnuiLgqNdsEmjQtO3L8tfrfGcksb7K3siPDomcya1NPkIsmInHy3KB4yv8ATcVQS1rIQ/6I8/vb5OBoVKa9dLm42C5lVcBd9SFqCIxy49Z52DU7y48LmDayUvtrHZx5gI61mV2/CWDhwWSnAD9l/f/s8IjHxuuWzYfaRaO+6ROY380TNIigjTswIDAQAB",
  "wrappedKey": "DWscCbnT63FJuU7dQueXverB31cU0A49omSHw98aqlkW/8qiKuyQgWss9QNp/8qB97xjheJxQcozKrkbulF1ExCfSFuGXR++psel8LFiXoreDRwxJPO/Fqbqf9bIBLpOHx6GLjbUze4fWEGHs1Dt22GHHLvkaHgFPc+sBZcHvHnKF1+iKFonFXSDfUODozNV/poyi1UJ6RrXX/HIgbUlkUos02FcTn9qQqATRUj4lAY0tgFJlqJdpiQJDOWcWV3DJtaPIU2qPo9i95xFDzXBZbb6j/zp6518urFh8hSQKJUG4JPI0yeeW3iTEgN6EUTl0gYXgGvYDQIbeCM+oRZj+A==",
  "iv": "dITA6JK5SUBeP/Hgn6xf1w==",
  "type": "encryptedData",
  "format": "DER_BASE64",
  "signature": "wkkhQVZW3MdQtZha/AKf6hdIntKQI74vvYwKG+VtxUN+XXup2GkeNXWzJJY51YQC2/3EPwn6n+lUXm2xCRjV4ICY3+A0nbZrZnNrG0t6QpDWIQz1g9YYLe8pysjym95CsKy7AlXgo43BX811fv+aShQQTRkLwur5/geHF8idIeYORqt0B/9pwOnjfZnshT4Cj5ILwoe2VKZ3eWnIxND1a3Z8rE0s6WTFojFbshGQU6pf8dOj8w0cD6EDuOnEQ7Y40GbdwR9G3PhDY/JhMUjODhP+5X9nXesW2VlMPXE0byNhtzbnzg5Yi0pP9eBr7t5fTjwBTg5XjR4qDZKeyF0pqQ=="
}

Reading plain text is the reverse process, your app will need to change some of the properties of the received object:

var readCipherObject = receivedCipherObj; // an object received via the app 
readCipherObject.type = "read"; 
readCipherObject.authorName = "Alice"; 
readCipherObject.keyID = myKeyID; 

var request = window.navigator.bridge.getCipherObject(readCipherObject); 
request.onsuccess = function (){ */ this.result.verification contains the 'verification' boolean /* }; 
request.onerror = function (error){};

The reading UI looks like:

Upon clicking “Decrypt”, the content changes to plaintext:

The plain text is read inside the reading widget and is keep out of the content DOM. A validation boolean property is returned in the success event handler, none of the text.

This UI in this addon is only a part of the point of it. I have long wondered how crypto can be used more safely in web apps – where we don’t have to worry about keys being stolen and primitives being ‘monkeypatched’. I am fairly certain the UX can be made much better. The main idea I want to get across is the internal API. It is quite simple. Once you have a keypair, you can do “hide()” and “show()” – similar to the simplicity of Dan Bernstein’s NaCL (box/unbox).

Sign() and Verify() are also in the works. I would also like for this API to support IETF’s JOSE formats.

If you would like to give “nulltxt” a try, (remember, nulltxt is EXPERIMENTAL ONLY), the addon is hosted here: https://addons.mozilla.org/en-US/firefox/addon/nulltxt/

A demo page is hosted here: https://nulltxt.se/nulltxt/demo-code/demo.html

And, of course, the source code is here: https://github.com/daviddahl/nulltxt-extension/

Let me know what you think of this approach. I can imagine a web application where the web site only ever handles ciphered data and provides no crypto in the DOM – offloading all of it to the browser chrome. Of course, there are still attack surfaces here, mainly around spoofing the browser chrome UI. With a severe CSP in place, I think this approach might work well.

W3C Web Crypto API – First Public Working Draft published

Good news! With a lot of hard work – I want to tip my hat to Ryan Sleevi at Google  – the W3C Web Crypto API First Public Working Draft has been published: http://www.w3.org/TR/WebCryptoAPI/
If you have an interest in cryptography or DOM APIs and especially an interest in crypto-in-the-DOM, please read the draft and forward any commentary to the comments mailing list: public-webcrypto-comments@w3.org

Countermeasures needed now

When I found out I could choose my own title at Mozilla I was ecstatic.

Of course coming up with a good one is another matter, I thought about it for days and days…

I thought about my “newbie” place at Mozilla and dredged my unconscious memory of all of the movies I had ever seen and chose the title: “Civilian Observer“.

Folks who have seen my business card are aghast – “What the hell does that mean?”

Surely you remember the 1980 movie “The Final Countdown” starring none other than Martin Sheen? (For my millennial readers, that is Charlie Sheen’s old man). His role was that of “Civilian Observer” on board the USS Nimitz.

From Wikipedia:

In 1980, the supercarrier USS Nimitz (CVN 68) takes on a civilian observer, Warren Lasky (Martin Sheen), at the orders of his reclusive and mysterious employer, Mr. Tideman (who helped design much of the ship), just before it departs Pearl Harbor for a training mission in the Pacific Ocean. Out in the Pacific, the ship encounters a strange storm-like vortex which disappears after the ship passes through it.

Naturally, I am not going to spoil it for you, but the Civilian Observer helps try and figure out alternative ideas for the strange place the ship finds itself in.

In working on open source or free software, you know there is a lot at stake. I feel like all of us are observing the growth of the internet and with it the growth of attempts at curtailing the power that this computer network gives us. We are seeing more and more of the growth of surveillance technology, some of which is created in Silicon Valley – technology that is used to prevent and record private communication, help identify and  round up and torture or kill dissidents all over the world.

The battle for the Web and the Internet is a full on war. It will always be that way. The issues of privacy vs. surveillance, open or closed software stacks and walled gardens are here to stay. We must be vigilant and we must create tools that fight and overturn the impulse to control or subordinate and use people and networks of people.

I have felt like the “Civilian Observer” since before I started at Mozilla, its just become more pronounced in the past few years. Take for instance, a smattering of my Twitter feed – tweets and links selected in the past day, mere hours:

Sometimes these tweets pop up right after one another:

Wow!, right?

Recently, WikiLeaks published a database of surveillance companies that produce tools that provide “Mass interception of entire populations…“.

These tools deployed on a mass scale essentially turn the Internet into a surveillance system.

We need more Countermeasures for this.

Firefox is one of these countermeasures, without it we would really be in a world of pain. I cannot even imagine how craptastic the net would be without Firefox.

Mozilla’s Boot2Gecko project is also a countermeasure. If we pull this off, it will truly be a Coup d’état in the mobile device space. The goal: building mobile phone apps from HTML, JavaScript and CSS! That is the way it should be.

Deuxdrop is another project in Mozilla labs trying to create a secure messaging system – I have high hopes for it. Again, these are the kinds of tools that need more focus.

I have been working on DOMCrypt for a few years now. DOMCrypt provides a Cryptography API in web pages, making it trivial and fast to encrypt data that may be part of a message to another web user or data that should stay private while stored in LocalStorage (amoung many other use cases). I am proud to say we have implementation bugs and plans lined up for both Gecko and WebKit. The W3C is using the API as the strawman proposal for the Web Cryptography Working Group. Web developers will be able to use strong and fast crypto via a DOM API. Exciting stuff.

Web developers are way out in front on this issue – there are several crypto libraries for JavaScript out in the wild, and developers are using them to push the envelop in web apps.

This is great stuff, but we need safer, built-in crypto APIs for browsers to provide a foolproof way to use crypto in the browser, not to mention the speed boost you get when calling native code APIs vs. native JavaScript functions. The other thing we need are new ways to communicate. The Web has won as the default communication channel and developers need to be able to write apps that allow people to communicate without sharing the conversation with a 3rd party.

Not sharing data with a 3rd party is the key issue. This concept destroys a lot of business models, well, one business model – the one everyone seems to think will work long term. I doubt that. Here’s a business model you can try: make a cool product and charge people a small fee to use it while simultaneously preserving their privacy. Novel, isn’t it?

What can you do to help? You can demand privacy and security be a feature of the products you use, not an afterthought. You can help test or help develop “countermeasure” applications.

Wikipedia lists several applications that enhance communications with more security:

https://en.wikipedia.org/wiki/Secure_communication#Programs_offering_more_security

(The link above does not mention  Tahoe-LAFS – please comment if you know of any more notable applications or toolkits)

I hope the future will bring a slew applications and startups that trumpet privacy and security enhanced applications. I hope web developers begin to think about more creative uses of their talents than online coupons and advertising-funded social media. The future of online privacy and security is both bright and bleak. Bright in that we have the CPU power, talent and base algorithms sitting right in front of us. It may seem bleak if you think no one cares about privacy or there is no ‘free lunch/free beer’ business model.

Another thing you can do is support organizations that are “watching the watchers”, the EFF, Privacy International and others. A great resource for this is privacy.org.

The Final Countdown Poster

A Working Group

This week I attended the W3C annual meeting known as “TPAC” in Santa Clara. I went to discuss the possible formation of a “Web Identity Working Group” to begin the process of possibly standardizing Identity APIs and protocols, of which DOMCrypt was acting as a straw man proposal for a DOM/JS Crypto API.

The short story is that “Web Identity” APIs and protocols are still very much in an R&D phase and while incredibly important, there was not much agreement between interested parties on what to begin working on.

A high-level, hard-to-muck-up, asynchronous crypto API, on the other hand, had massive support from almost all of the interested parties involved. In the end, a “Web Cryptography Working Group” is being established, and I have thrown my hat into the ring as an “editor candidate”.

One of the first tasks is to clearly define what is “in scope”, “out of scope” and what features can be considered part of a potential “road map”. The starting point for this API will have to be a bit narrow, with no UI-based features so we can establish core functionality without too much complexity.

The current charter is here: http://www.w3.org/wiki/IdentityCharter#Web_Cryptography_Working_Group_Charter (I have a feeling this url will change soon)

This is pretty exciting stuff. I met with a whole lot of folks from Microsoft, Google, Apple, Netflix and other companies that have many potential use cases. We need to collect as many use cases as possible in order to understand the most common uses so the first iteration will provide the best capabilities. If you have a use case in mind, do not hesitate to send it to me (ddahl + at + mozilla dot com) or the w3 mailing list, public-webcrypto@w3.org (which is yet to be set up).

JavaScript and crypto

After reading this thought-provoking post: http://www.matasano.com/articles/javascript-cryptography/ I thought I would enumerate some of the concerns raised and try to explain how DOMCrypt handles at least some of problems that are inherent in JavaScript cryptography.

• DOMCrypt is not a low-level crypto API. DOMCrypt is very high-level, making it much harder to ‘do it wrong’. The only configuration is telling DOMCrypt what algorithm to use. See: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
• Private key material is never exposed to content JS. Each keypair is represented by an ID. This keeps the key material in a secure key store outside of content. (In the case of Firefox, the key material will be stored in NSS’ key database)
• Each domain/origin will have its own keypair. You will have to know the ‘KeyID’ to use the domain’s keypair to encrypt data. Being able to handle secret key material in content is ‘doing it wrong’. The original DOMCrypt prototype code as well as all of the crypto libraries do this. Not good.
• All algorithms are well designed, well tested and maintained crypto functions created by tried and true cryptographers (In the case of Firefox’s implementation we have NSS under the covers). Millions of users have depended on this underlying crypto for a decade plus. Part of the motivation for DOMCrypt is that each site might roll their own crypto implementation, or use an implementation that is out in the wild, which are likely to be subtly wrong.  By providing DOMCrypt, we can leverage all the careful scrutiny that has already gone into browser crypto implementations. We are not re-building the wheel. (Random numbers are truly random as we are calling into NSS or other system crypto depending on the browser implementation)
• Fast. This is not a concern in the Matasano article, but I think it is a valid point. DOMCrypt calls crypto functions written in C, so all of the crypto operations are quite fast.

There are, of course, still many concerns even with a built in crypto API, but I think it is a step in the right direction. Moving all of the heavy crypto operations into the browser itself and exposing only a high-level API to consumers is the beginning. Making encryption as trustworthy as possible in a malleable content JavaScript environment will take some additional work.

 

*thanks to Adam Barth for input

DOMCrypt update: Symmetric API first iteration

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.

Use Cases and Apps

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

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:

• WHATWG: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-May/031741.html
• W3C: http://lists.w3.org/Archives/Public/public-web-security/2011Jun/0000.html
• es-discuss: https://mail.mozilla.org/pipermail/es-discuss/2011-June/014892.html

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.

DOMCrypt API Update 2011-06-01

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:

• https://bugzilla.mozilla.org/show_bug.cgi?id=649154
• https://bugzilla.mozilla.org/show_bug.cgi?id=657432

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.

>Firefox Bookmarks & History Query API (re)Design

>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: http://blog.mozilla.com/faaborg/2009/10/13/browsing-your-personal-web/

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: https://bugzilla.mozilla.org/show_bug.cgi?id=522572

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: https://bugzilla.mozilla.org/show_bug.cgi?id=523519