Privacy/Reviews/BrowserID.org
Document Overview
| Feature/Product: | BrowserID.org |
| Projected Feature Freeze Date: | (tbd) |
| Product Champions: | Dan Mills, Ben Adida |
| Privacy Champions: | Sid Stamm |
| Security Contact: | Michael Coates |
| Document State: | [NEW] |
Timeline:
| Architectural Overview: | August, 2011 |
| Recommendation Meeting: | (date TBD) |
| Wrap-up Meeting: | (if necessary) |
Architecture
In this section, the product's architecture is described. Any individual components or actors are identified, their "knowledge" or what data they store is identified, and data flow between components and external entities is described.
The main objective of this feature/product is: browserid uses a simple protocol (verified email) to implement sign-ins on sites that is secure, password-free, and very easy to use.
Project highlights:
- Single-click sign-up/sign-in/sign-out. No need to remember passwords for each site
- Browser integration, for maximum convenience and protection from phishing attacks
- Mobile Firefox support, making it easy to sign up and use sites on mobile phones
- Support for current-generation browsers, no special add-ons required (using HTML pop-ups)
- Provides an on-ramp towards a fully decentralized system, with the user agent as ID mediator.
The Mozilla Identity project has several initiatives:
- A protocol specification (Verified Email)
- A Mozilla-hosted service (This, browserid.org)
- Clients for Firefox, Firefox Mobile, and a pure-HTML client with support for a variety of browsers
This privacy review addresses only the Mozilla-hosted service, browserid.org.
Design Documents:
Link to any design or architectural documents here.
Feature pages:
- Identity/Features/Verified_Email_Service
- Identity/Features/Verified_Email_Service_Admin_Interface
- Identity/Features/Web-based_Verified_Email_Client
- Identity/Features/Firefox-native_Verified_Email_Client
- Identity/Features/Mobile_Firefox_Verified_Email_Client
Components
- Browserid.org verifier
- Browserid.org implementation server
- Relying party (sites deploying the sign-on)
- RP user agent window (e.g., Firefox loading the RP site)
- Sign-In user agent window (e.g., Firefox loading the pop-up browserid sign-on)
- email provider
Verifier
This component verifies cryptographic assertions that a user controls a given email address. It loads domain public keys from DNSSEC and/or a well-known location at the email provider's web site. In an ideal system, the relying parties would do this verification themselves, but in the meantime we must implement one as an on-ramp.
The tables below simply summarize the data encountered by this component.
Stored Data:
| What | Where |
|---|---|
| relying party hostname and time | logs |
Communication with DNS and/or domain web sites
| Direction | Message | Data | Notes |
|---|---|---|---|
| Out: | get public key | - | |
| In: | get public key | domain public key |
Communication with Relying Party
| Direction | Message | Data | Notes |
|---|---|---|---|
| In: | verify assertion | user email address, certificate, timestamp and relying party hostname | |
| Out: | verify assertion | success flag and, if true, user email address, timestamp, and relying party hostname |
Implementation Server
This component serves the Verified Email protocol code to the user agent -- at the relying party's request. When an RP wants to use browserID, they hotlink to resources on the Implementation Server to connect to the system.
The tables below simply summarize the data encountered by this component.
Stored Data:
| What | Where |
|---|---|
| user email addresses | database |
| bcrypted password | database |
Communication with BrowserID User-Agent Window
| Direction | Message | Data | Notes |
|---|---|---|---|
| In: | register() | user's email and a password | Password is for browserid.org, not the email account |
| In: | signin() | user's email and a password | Password is for browserid.org, not the email account |
| Out: | list_emails() | user's list of validated email addresses | only when user is successfully logged in |
| In: | add_email() | new user email | only when user is successfully logged in |
BrowserID User-Agent Window
This component is a browser window that contains content in the origin "https://browserid.org". This is a combination of code served from the Implementation Server component and the browser's local storage data for this domain. It communicates with the BrowserID Implementation Server, which is its expected backend server, and with the RP User-Agent Window, using a postMessage channel.
Stored Data:
| What | Where |
|---|---|
| email ownership certificates | localStorage for https://browserid.org |
Communication with Implementation Server
See the Implementation Server section.
Communication with RP User-Agent Window
| Direction | Message | Data | Notes |
|---|---|---|---|
| In: | getVerifiedEmail() | RP hostname | inherently via postMessage |
| Out: | getVerifiedEmail() | certificate and signed assertion of email, time, and RP hostname | via postMessage, to other browser window. |
Relying Party (external)
This external component provides a service to the user and requests that the user log in using BrowserID. It communicates with the Verifier service and with its own RP Window.
Stored Data:
| What | Where |
|---|---|
| data type | where stored |
Communication with Component Y
| Direction | Message | Data | Notes |
|---|---|---|---|
| In: | message 1 | types of data received from component Y with the message | |
| Out: | message 2 | types of data sent to component Y with the message |
RP User-Agent Window (external)
It communicates with the BrowserID dialog via a JavaScript APIIn the short-term, this communication is mediated by a JavaScript shim served by Browserid.org. In the longer term, this communication is provided as a browser feature. Since this is an external module, we don't know much about its data transfers except with our components.
Communication with Component BrowserID User-Agent Window
See BrowserID User-Agent Window section.
Email Provider (external)
This component does A, B and C and interacts with component Y to do D.
The tables below simply summarize the data encountered by this component.
Stored Data:
| What | Where |
|---|---|
| data type | where stored |
Communication with Component Y
| Direction | Message | Data | Notes |
|---|---|---|---|
| In: | message 1 | types of data received from component Y with the message | |
| Out: | message 2 | types of data sent to component Y with the message |
User Data Risk Minimization
In this section, the privacy champion will identify areas of user data risk and recommendations for minimizing the risk.
Alignment with Privacy Operating Principles
In this section, the privacy champion will identify how the feature lines up with Mozilla's privacy operating principles.
See Also: Privacy/Roadmap_2011#Operating_Principles:
Principle: Transparency / No Surprises
(How the feature addresses this)
Recommendations: (what can be improved)
Principle: Real Choice
Recommendations:
Principle: Sensible Defaults
Recommendations:
Principle: Limited Data
Recommendations:
Follow-up Tasks and tracking
| What | Who | Bug | Details |
|---|---|---|---|
| [NEW] Initial Overview Discussion | ? | Meeting time TBD |