Privacy/Reviews/AccountProvisioner

Document Overview

Feature/Product:	Account Provisioner
Projected Feature Freeze Date:	2011-11-08
Product Champions:	Blake Winton
Privacy Champions:	Sid Stamm
Security Contact:	Curtis Koenig
Document State:	[AT RISK] needs log retention policy

Timeline:

Architectural Overview:	July 2011
Recommendation Meeting:	(date TBD)
Review Complete ETA:	Dec 2011

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: to provide users with a way of signing up for an email account from within Thunderbird.

Design Documents:

I thought there were some, but the design seems to have been done entirely on paper and in conversations. Which is probably reasonable in this case, because it's quite simple. I do have a blog post with some mockups at [1], and the code is at [2].

The current implementation has three parts, an add-on for Thunderbird ("the add-on") which presents the UI, a Mozilla Messaging server component ("the server") which is responsible for telling the add-on what services are available, and collecting and grouping the email address suggestions, and the various third-party email provisioning APIs ("the providers"). (In the near future, the add-on will become core Thunderbird code.)

For details, see below:

There are three main interactions, labelled "A", "B", and "C" in the diagram above.

A) Initial Display.

1. When the user chooses to configure a new email account, the add-on takes over, and contacts the server to get a list of providers and the information the add-on needs to contact each provider. An example of the current information is at [3]. Note the "api" field which can contain either an array of fields or a url.
2. The server returns that information. (It is expected to be static, and probably stored as a file.)

B) Getting Suggestions.

3. Once the user enters their first and last name (or any two other words they choose), the add-on sends that and the user's country code to the server.
4. The server contacts the various providers to get lists of available email addresses. (4a, 4b, and 4c happen in parallel.)
5. The providers return suggested available email addresses. (5a, 5b, and 5c happen in parallel.)
6. The server then collates those lists into a single list, and returns it to the add-on. An example of the collated list is at [4]
   The add-on will take the list of suggestions, and display them to the user.

C) Getting an Account.

7. Once the user chooses a suggested email address, the add-on will open up a browser tab in Thunderbird pointing to the url returned from the previously mentioned "api" field. (The "api" field used to also be permitted to contain an array of fields, in which case the add-on would construct and display the registration UI itself, and pass the collected data to the provider's url. We don't really want to do that, though, for branding reasons.)
8. The browser tab will display pages hosted on the provider's server, leading the user through the sign-up process. (8a, 8b, 8c, and 8d happen sequentially, but are all basically the same communication of http requests/responses.)
9. Once the user has finished signing up for an address, the provider will return an XML page, which Thunderbird will intercept (based on content-type). Thunderbird will then use the information in that XML page to create the user's account in Thunderbird.

Components

Describe any major components in the system and how they interact. Also include any third-party APIs (those Mozilla does not control) and what type of data is sent or received via those APIs.

• Thunderbird Addon component.
• Mozilla Messaging server component.
• Third party email providers component.

Note: All communications will be over secure channels. HTTPS for the things mentioned below, and IMAPS/SMTPS for the newly-created account.

Thunderbird Addon

This component displays the UI to the user, and creates the account once the user has signed up with a provider.

It interacts with the Mozilla Messaging server to get the configuration at startup, and to get the list of suggested email addresses.

It interacts with the selected third party email provider through a browser tab to allow the user to sign up, and to get the data to create the account.

The tables below simply summarize the data encountered by this component.

Stored Data:

What
None.

Communication with Mozilla Messaging server

Direction	Message	Data	Notes
In:	(2) http response for /provider/list	static configuration info, in JSON.	See [5]
	(6) http response for /suggest	static configuration info, in JSON.	See [6]
Out:	(1) http request for /provider/list	None.
	(3) http request for /suggest	First name, last name, client IP.

Communication with third party email provider

Direction	Message	Data	Notes
In:	(8b, 8d) sign-up page(s)	html	There may be more than one page in the sign-up process.
Out:	(8a, 8c) http request for first sign-up page.	First name, last name, selected email address, client IP.

Mozilla Messaging server

This component sends the configuration data to the addon, and gets and collates the list of suggested email addresses from the third party providers.

It interacts with the addon to send it the configuration at startup, and to get the first and last name to get the list of suggestions.

It interacts with the selected third party email providers to get the list of suggestions to return to the addon.

The tables below simply summarize the data encountered by this component.

Stored Data:

what	where	notes
client ip.	http logs.	this is inadvertent, and should be purged (or collected into stats, and then purged) on a regular basis.

Communication with addon

Direction	Message	Data	Notes
In:	(1) http request for /provider/list	None.
	(3) http request for /suggest	First name, last name, client IP.
Out:	(2) http response for /provider/list	static configuration info, in JSON.	See [7]
	(6) http response for /suggest	static configuration info, in JSON.	See [8]

Communication with third party email provider

Direction	Message	Data	Notes
In:	(5a, 5b, 5c) http response for suggested email addresses.	suggested email addresses and prices in JSON.
Out:	(4a, 4b, 4c) http request for suggested email addresses.	First name, last name, client country code.	Not client IP address.

Third party email providers

This component returns the list of suggested email addresses, and creates the account.

It interacts with the addon through a browser tab to allow the user to sign up, and to return the data to create the account.

It interacts with the Mozilla Messaging server to return the list of suggested email addresses.

Note: We don't write this component, and have limited influence over what it does.

The tables below simply summarize the data encountered by this component.

Stored Data:

what	notes
Unknown.	Since this is the third-party server, we should assume they store everything they can.

Communication with the addon

Direction	Message	Data	Notes
In:	(8a, 8c) http request for first sign-up page.	First name, last name, selected email address, client IP.
Out:	(8b, 8d) sign-up page(s)	html	There may be more than one page in the sign-up process.

Communication with Mozilla Messaging server

Direction	Message	Data	Notes
In:	(4a, 4b, 4c) http request for suggested email addresses.	First name, last name, client country code.	Not client IP address.
Out:	(5a, 5b, 5c) http request for suggested email addresses.	suggested email addresses and prices in JSON.

User Data Risk Minimization

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

Breach and Log Disclosure

The Risk is that information logged by the Mozilla Messaging server will be unintentionally disclosed to untrusted third parties through a breach event.

Recommendation: Work with infrasec and IT/Ops to minimize logging, minimize retention window, and deploy a secure logging infrastructure.

Resolution:

[NEW]

Unintended Identity/PII Broadcast

The Risk is that users may not intend to spread their name to email providers they do not trust.

Requirement: disclose to which third parties their name will be transmitted. Also make it clear what other types of data (if any) are transmitted to the third parties along with the user's name.

Recommendation: allow users to pre-select which of the service providers to query about a new account. Make it clear in the UI who the user is interacting with via logos and service provider names. (Screen shot showing the UI. Another screen shot showing the UI after showing providers for all locales.)

Resolution:

[RESOLVED] Users have control, via UI checkboxes, to which third parties their name is sent.

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

This feature isn't activated at all until a user attempts to set up a new account. At that time, the Mozilla server is contacted (and provided with nothing other than a standard HTTP request) and a list of suggested account providers is returned. Until the user takes more action, such as entering their name and asking for suggestions, no more communications are triggered. Information is not disclosed until users take action, and the information disclosed is directly provided within the context of that action.

Recommendations: none.

Principle: Real Choice

The feature is not active by default, and unless a user activates the feature to create a new account, no information is collected or disseminated. It is clear in the use of the feature what information users are disclosing and to whom.

Recommendations: none.

Principle: Sensible Defaults

This feature is not activated by default, though it is available for use by all Thunderbird users who wish to activate it.

Recommendations: none.

Principle: Limited Data

The minimal amount of data for each transaction is provided, and it should not be retained by Mozilla servers longer than necessary for the requested transaction (and for security-related logging).

Recommendations: Work with infrasec and IT/Ops to minimize logging, minimize retention window, and deploy a secure logging infrastructure.

Resolution:

[NEW]

Follow-up Tasks and tracking

What	Who	Bug	Details
[DONE] Initial Overview Discussion	Blake and Sid		Held July 2011
[DONE] Security review	Secteam + others		Held 2011-08-19
[DONE] Initial Risk Analysis	Privacy team		December 2011
[DONE] Public Discussion	mozilla.dev.planning		December 2011
[DONE] Discuss requirements and recommendations with team	Sid & Blake		TBD
[AT RISK] log retention policy	Michael Coates (mcoates)	741810
[DONE] Add country code details	Blake and Sid	752618	May 2012