Privacy/Reviews/AccountProvisioner

Document Overview

Feature/Product:	Account Provisioner
Projected Feature Freeze Date:	(tbd)
Product Champions:	Blake Winton
Privacy Champions:	Sid Stamm
Security Contact:	Curtis Koenig
Document State:	[NEW]

Timeline:

Architectural Overview:	(date TBD)
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: 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 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:	http response for /provider/list (2)	static configuration info, in JSON.	See [5]
	http response for /suggest (6)	static configuration info, in JSON.	See [6]
Out:	http request for /provider/list (1)	None.
	http request for /suggest (3)	First name, last name, client IP.

Communication with third party email provider

Direction	Message	Data	Notes
In:	sign-up page(s) (8b, 8d)	html	There may be more than one page in the sign-up process.
Out:	http request for first sign-up page. (8a, 8c)	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:	http request for /provider/list (1)	None.
	http request for /suggest (3)	First name, last name, client IP.
Out:	http response for /provider/list (2)	static configuration info, in JSON.	See [7]
	http response for /suggest (6)	static configuration info, in JSON.	See [8]

Communication with third party email provider

Direction	Message	Data	Notes
In:	http response for suggested email addresses. (5a, 5b, 5c)	suggested email addresses and prices in JSON.
Out:	http request for suggested email addresses. (4a, 4b, 4c)	First name, last name.	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:	http request for first sign-up page. (8a, 8c)	First name, last name, selected email address, client IP.
Out:	sign-up page(s) (8b, 8d)	html	There may be more than one page in the sign-up process.

Communication with Mozilla Messaging server

Direction	Message	Data	Notes
In:	http request for suggested email addresses. (4a, 4b, 4c)	First name, last name.	Not client IP address.
Out:	http request for suggested email addresses. (5a, 5b, 5c)	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.

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