Privacy/Features/mozCipherAddressbook
Status
| mozCipherAddressbookAPI | |
| Stage | Planning |
| Status | ` |
| Release target | ` |
| Health | OK |
| Status note | Design and Implementation exists in an addon: DOMCrypt. (Needs porting) |
Team
| Product manager | Chris Blizzard |
| Directly Responsible Individual | Dietrich Ayala |
| Lead engineer | David Dahl |
| Security lead | Sid Stamm |
| Privacy lead | Sid Stamm |
| Localization lead | ` |
| Accessibility lead | ` |
| QA lead | Juan Becerra |
| UX lead | Alex Limi |
| Product marketing lead | ` |
| Operations lead | ` |
| Additional members | ` |
Open issues/risks
`
Stage 1: Definition
1. Feature overview
A simple API for exchanging public keys via web page metatags as an enhancement to the DOMCryptAPI (mozCipher), see: Privacy/Features/DOMCryptAPI.
Goals: As simple as possible mechanism for web users to discover and save public keys as a helper for the DOMCryptAPI.
2. Users & use cases
DOMCrypt (see Privacy/Features/DOMCryptAPI is a public key crypto API, which is useful as-is, but to enhance the user experience, a simple method to collect and store your contact's public keys would make DOMCrypt a bit more powerful. This simple API adds to window.mozCipher (which is provided by DOMCrypt):
window.mozCipher.getAddressbook();
It also adds a browser-side notificationbar that is displayed when a "addressbook-entry" meta tag is encountered. This notificationbar asks the user to save or ignore the "contact entry". This is a very simple way for endusers to exchange public keys and is presented in a language that is easily understood. Users need each other's addressbook entry to exchange private message data. This simplifies the nomenclature greatly, which will help bring more user control and privacy to users who care to exchange data on the web in a more secure manner.
3. Dependencies
`
4. Requirements
Parsing the DOM on idle to discover "addressbook-entry" meta tags would make the most sense - there is a little bit of research to do here on perf.
Non-goals
Any kind of key management UI or toolkit.
Stage 2: Design
5. Functional specification
The existing implementation is here: [1]
A demo can be found here: [2]
6. User experience design
`
Stage 3: Planning
7. Implementation plan
Next Steps & Open Issues
Port the existing synchronous API over to an asynchronous API
Related Bugs
8. Reviews
Security review
`
Privacy review
`
Localization review
`
Accessibility
`
Quality Assurance review
`
Operations review
`
Stage 4: Development
9. Implementation
`
Stage 5: Release
10. Landing criteria
`
Feature details
| Priority | P3 |
| Rank | 999 |
| Theme / Goal | ` |
| Roadmap | Privacy |
| Secondary roadmap | ` |
| Feature list | Platform |
| Project | ` |
| Engineering team | DOM |
Team status notes
| status | notes | |
| Products | ` | ` |
| Engineering | ` | ` |
| Security | ` | ` |
| Privacy | ` | ` |
| Localization | ` | ` |
| Accessibility | ` | ` |
| Quality assurance | ` | ` |
| User experience | ` | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |
