Privacy/Features/mozCipherAddressbook

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

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

bug 657432

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