Privacy/Reviews/BrowserID.org

From MozillaWiki
Jump to navigation Jump to search

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:

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 assertions that a user controls a given email address, and interacts with email providers to validate the user's control (by sending the challenge/response emails). In an ideal system, the email providers would do the 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
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

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

Relying Party (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

RP User Agent Window (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

Sign-In User Agent Window (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

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