Document Overview

Timeline:

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.

• Labs/Identity/VerifiedEmailProtocol
• Identity/MozIDNotes -- whiteboard
• Identity/Hackfest2011

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

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.

• Browserid.org verifier
• Browserid.org 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)

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:

Communication with DNS and/or domain web sites

Communication with Relying Party

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:

Communication with BrowserID User-Agent Window

Communication with Email Provider User-Agent Window

Communication with Email Provider

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:

Communication with Implementation Server

See the Implementation Server section.

Communication with RP User-Agent Window

Communication with Email Provider User-Agent Window

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:

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

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 browserid.org 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 browserid.org. Some sites may require use of browserid.org 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, browserid.org 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.

Follow-up Tasks and tracking