From MozillaWiki
Jump to: navigation, search
Please use "Edit with form" above to edit this page.


DOMCryptAPI (a Crypto API in the DOM)
Stage Shelved
Status `
Release target `
Health `
Status note THIS API DESIGN IS SUPERSEDED BY Currently a Firefox Extension as well as the 'strawman' proposal for a new W3C standard, DOMCrypt adds a new Window property that wraps NSS crypto functions, see and


Product manager Chris Blizzard
Directly Responsible Individual Sid Stamm
Lead engineer David Dahl
Security lead Brian Smith
Privacy lead Sid Stamm
Localization lead `
Accessibility lead `
QA lead Juan Becerra
UX lead `
Product marketing lead `
Operations lead `
Additional members `

Open issues/risks


Stage 1: Definition

1. Feature overview

DOMCrypt gives web developers and endusers control over who data is shared with in plain text. DOMCrypt will provide Public Key Encryption, Symmetric Encryption, HMAC, and Hashing to DOM scripting.

Goal: Provide an elegant "webby" crypto API web developers can use to allow more user control of messages and data typed into Firefox

2. Users & use cases


3. Dependencies


4. Requirements


  • Initially supporting complex Crypto standards
  • Hardware device support

Stage 2: Design

5. Functional specification

Draft spec:

Also See and

6. User experience design

This is a JavaScript DOM API - it's draft spec specifies no UI at this time. The experience will be a mostly asynchronous API

Stage 3: Planning

7. Implementation plan

Next Steps

  • Get the discussion going with other browser vendors, WHAT-WG, W3C, TC-39
  • Develop an implementation schedule
  • Port extension over to Firefox/DOM code: underway
  • Test suite - underway
  • Will integrate DOMCryptAPI with window.crypto


  • This code is heavily based on parts of WeaveCrypto that was excised from mozilla-central, when Sync switched to J-PAKE crypto

8. Reviews

Security review

Review by Brian Smith, additional superreview will be required - perhaps by WTC or Kai Engert

Privacy review


Localization review




Quality Assurance review


Operations review


Stage 4: Development

9. Implementation

The implementation may re-use the extension code after it is refactored to use ArrayBufferViews and the internal secure key store, with a final implementation that completely replaces the original extension code. The reason for this is that it has been incredibly useful and instructive to have a working implementation to demo the capabilities to web developers and privacy people. The original extension code will be replaced entirely.

The extension code uses js-ctypes witch can cause some erratic NSS behavior.

Stage 5: Release

10. Landing criteria

(TBD, not exactly sure what to put here, feel free to add some sample criteria -ddahl)

Feature details

Priority Unprioritized
Rank 999
Theme / Goal Security Leadership
Roadmap Security
Secondary roadmap Developer Tools
Feature list Platform
Project `
Engineering team Security

Team status notes

  status notes
Products ` `
Engineering ` `
Security sec-review-needed bug 744938
Privacy ` `
Localization ` `
Accessibility ` `
Quality assurance ` `
User experience ` `
Product marketing ` `
Operations ` `

Other Documentation

David Dahl has been working on this project over the past couple of years as a side project. Starting with content-based crypto via wordpress' AES implementation, moving to WeaveCrypto-based extensions and sites like - the realization dawned that starting small is the best bet in this endeavor: a single DOM property.