From MozillaWiki
Jump to: navigation, search

Document Overview

Projected Feature Freeze Date: July 2011
Product Champions: Dan Mills, Ben Adida
Privacy Champions: Sid Stamm
Security Contact: Michael Coates
Document State: [AT RISK] awaiting resolution


Architectural Overview: August, 2011
Recommendation Meeting: Async via email
Review Complete ETA: Nov 2011


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,
  • 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,

Design Documents: Link to any design or architectural documents here.

Feature pages:



Dotted lines denote communication and external entities outside of this system. Externally controlled components may use BrowserID or be used by BrowserID, but may not be controlled by Mozilla. Also, dotted lines denote communications between external entities; we can make assumptions about some of the data transferred in these paths, but not all.

  • verifier
  • implementation server
  • 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 User-Agent Window (Firefox loading a webmail site)
  • Relying party (External - uses BrowserID for sign-in)
  • Email Provider (External)
  • DNSSEC system (External)


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, not the email account
In: signin() user's email and a password Password is for, 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

Communication with Email Provider User-Agent Window

Direction Message Data Notes
Out: provision() user's email entered by the user, email provider has to check that corresponding user is logged in
Out: generateKeyPair() public key generated for certification
In: storeCertificate() certificate for the public key previously generated

Communication with Email Provider

Direction Message Data Notes
In: lookupDomainParameters() domain public key, provisioning URL, login URL served at well-known URL or via DNSSEC records

BrowserID User-Agent Window

This component is a browser window that contains content in the origin "". 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

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.

Communication with Email Provider User-Agent Window

Direction Message Data Notes
Out: provisionCert() email address, public key
In: provisionCert() certificate binding public key and email address with expiration date

Relying Party (external)

The relying party back-end communicates with its own RP User-Agent window, and optionally with the Verifier service.

Communication with RP User-Agent Window

This communication is between two external components we don't control. At a minimum, we expect the following:

Direction Message Data Notes
In: login() assertion obtained by RP User-Agent Window from BrowserID User-Agent Window

Communication with Verifier Service

See the Verifier communication section.

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

Communication with Relying Party

See Relying Party communication section

Email Provider User-Agent Window (external)

Email Providers can be come Primary Identity Providers for BrowserID. They communicate with BrowserID via their User-Agent window, e.g. when a user logs into their web-based email.

Communication with BrowserID User-Agent Window

See BrowserID User-Agent Window communication Section.

Email Provider

The email provider communicates with its user-agent window in the usual way to let the user log in. For BrowserID specific features, it is very likely that the email provider's user-agent window will send the user's public key up to the email provider for certification, as certification typically happens on the server.

DNS and Domain Web Sites

A domain's web site and/or its DNSSEC records provide, for the world to see, some BrowserID parameters:

  • domain public key (one or more)
  • provisioning URL (where a logged-in user is automatically able to get a key certified)
  • login URL (where a non-logged-in user is sent to log in.)

User Data Risk Minimization

In this section, the privacy champion will identify areas of user data risk and recommendations for minimizing the risk.

User Enumeration

The Risk is that a malicious user with a list of email addresses can query the service to enumerate which of the listed email addresses are enrolled in BrowserID. Users may not want it world-known that they use this service to authenticate.

Recommendation: Rate Limit requests to the API so that a malicious user can't quickly brute-force check for which email addresses are enrolled.


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

The user clicks a browser ID button to sign into sites, he interacts with a browser ID pop-up window (clearly at a URL), and chooses what email addresses to use with browser ID. This all seems pretty straightforward and unsurprising.

The privacy policy has a plain-english and legal version, making it accessible to more people.

Recommendations: none.

Principle: Real Choice

Users are not required to participate in Some sites may require use of for authentication, but the user still controls which email addresses are used for authentication. Users can add/remove email addresses from their account as desired.

Recommendations: none.

Principle: Sensible Defaults

There's no automatic enrolment of addresses into Browser ID. Users choose which identities to use and on which sites.

Recommendations: none.

Principle: Limited Data

By nature, only collects and retains data necessary for connecting email addresses to third parties. Most of the mapping of email address to relying party is done in the browser's local storage (not on the server), though the server does learn the email-RP mappings.

Recommendations: Minimize retention of log data to what's necessary to operate and grow the site. Encourage email providers to act as primaries.

[AT RISK] bug 741810 document and make accessible what data is logged and for how long the data is kept

Follow-up Tasks and tracking

What Who Bug Details
[DONE] Initial Overview Discussion Sid & Ben 11-Oct-2011
[DONE] Risk Analysis Sid Stamm 19-Nov-2011
[AT RISK] Create and Publish data retention policy Ben Adida & Michael Coates bug 741810  ?
[AT RISK] Rate-limit requests to API to prevent guessing IDs ID team bug 671998  ?