Document Overview

Feature/Product:	F1 service and support for Firefox
Projected Freeze Date:	24-May-2011
Product Champions:	Shane Caraveo, Philipp von Weitershausen
Privacy Champions:	Sid Stamm
Security Contact:	Curtis Koenig
Document State:	[DROPPED] project respun as Client-Only

Timeline:

Architectural Overview:	24-March-2011
Recommendation Meeting:	27-April-2011
Wrap-up Meeting:	TBD

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 is: to share links from within the browser without leaving the page using the same services with whom you have an established relationship.

Components

There are three major components: chrome component, a webapp server (that serves the UI called a share panel), and a sharing server that takes care of authentication and sharing on behalf of the user.

The system interacts with Firefox on the client end, and also with third party sharing services like Twitter, Facebook, etc.

Standard operational flow is documented in Services/F1/Design.

Chrome Component

This component provides a button in the Firefox chrome that, when clicked, displays a door hanger. The contents of the door-hangar are provided by the webapp component, and that content is isolated from privileged code with the use of an iframe and postMessage() calls.

The API used via postMessage so the webapp component can communicate with the chrome bits of Firefox [1].

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

Stored Data:

What	Where
shareState	in memory only, associated with browser tab
oauth and/or openid user tokens, user profile and contacts	per service, encrypted using same classes that encrypt password storage in chrome, saved to file

Communication with Webapp Component

Direction	Message	Data	Notes
In:	success message	domain, username, userid, URL, service name	from webapp content
	getShareState	no data
	generateBase64Preview	no data
	UI content	stateless web content	HTTP-served data from Webapp server, loaded in an iframe.
Out:	shareState	options object, status (state of share), open (boolean)
	base64Preview	data:url with base64 image	containing the image preview of whatever is being shared.

There is also a chrome component/web component API to mimic local storage.

Communication with Sharing Server Component

Note: all of the communication with the sharing server are accomplished through the webapp component's content.

Direction	Message	Data	Notes
In:	none
Out:	none

Webapp Component

This component is comprised of a remote web application that serves the UI Firefox displays in its door hangar "chrome component." The UI served is static content (not based on any sort of state), and is provided via web server to enable quick and lightweight upgrades by the project team. The UI has only web page features, but talks to the chrome component via postMessage() for additional functionality.

The API used via postMessage so the webapp component can communicate with the chrome bits of Firefox is documented here: https://github.com/mozilla/f1/wiki/Chrome-Web-Data-API%3A-v1

Stored Data:

What	Where
User account/profile data and contacts	in-memory storage only, flushed on refresh, retrieved from chrome storage

Communication with Chrome Component

Direction	Message	Data	Notes
In:	postMessage calls()	various	See above section on chrome component
Out:	postMessage calls()	various	See above section on chrome component

Communication with Sharing Server

Direction	Message	Data	Notes
In:	/authorize response	signed capabilities	redirect to Verify request (OAuth)
	/verify response (OAuth)	account data object	API definition
	/send response (Custom)	error data or result	Result is heavily service dependent, from "SUCCESS" to a bit of context information about the share.
	/contacts response (Custom)	JSON blob containing list of contact objects (POCO format)	API definition
Out:	/authorize request	domain name of external service
	/verify request	OAuth/OpenID tokens from remote service
	/send request	domain,username,id token,account,link,message	API definition
	/contacts request	domain,username,id token,account,group, maxresults,startindex	API definition

Sharing Server

This component is a web application server that negotiates authentication on behalf of the user and sharing of data via OAuth. It acts as a proxy for all "share" requests, and may temporarily cache user data.

The API is documented in Services/F1/Server/API.

What	Where
user requests	in memory only
interim oauth/openid state	in memory session data, removed on completion of oauth/openid authorization

Communication with Chrome Component

NOTE: There is no direct communication between chrome and the share server.

Direction	Message	Data	Notes
In:	none
Out:	none

Communication with Webapp Component

Direction	Message	Data	Notes
In:	various API calls	various	See above section on webapp component
Out:	various API calls	various	See above section on webapp component

Communication with Third-Party APIs

Direction	Data	Notes
In:	users oauth tokens, username/id for service, share data	(see below)
Out:	Varied response data per 3rd party api	(see below)

Data shared with third-party APIs is specific to each third-party API. In general, it includes a user's ID (oauth token), and the URL to share. Other data relayed to the 3rd party may include intended recipients (userid, email address, etc), a short message and Open Graph data scraped from the web page being shared.

There is a detailed list of 3rd party api use in the security threat model.

User Data Risk Minimization

There are three categories of user data exposed by this feature, and each has its own corresponding risks. Each risk is identified as a potential problem, and recommendations for minimizing or avoiding the risk are provided.

Credentials

Various usernames and OAuth credentials for third party services (exposed to Mozilla). Ideally, Mozilla would have submit-only sharing access to the third parties, but as it currently exists the OAuth tokens used by the Mozilla Sharing Service for sharing are equivalent to login credentials.

The Risk is that we have unrestricted access to the user's third party accounts; compromise of the server or compelled wiretapping could be disastrous for not only our relationship with the user, but also for the privacy and integrity of their identities on the various third party sites. A compromise of this system could result in not only user-level access to their F1 capabilities, but potentially also identity theft by complete access to their capabilities on all third party sites including (but not limited to) password management, identity fraud, financial transactions, private information disclosure, etc.

Requirement: Alternatives to an OAuth proxy should be considered in the design of this service. The major source of risk in this case is having access to and control over use of the users' credentials for various third party sites. If the chrome component or webapp component's content could completely manage sharing and act on behalf of the user from the client side, this privacy risk would not exist.

Discussion

The level of account access varies among the 3rd party service providers, ranging from 
Twitter which has no real ACL to Facebook which kind of has ACLs.  With Twitter, since 
we need to post/write messages, we have 100% access to the account.  Facebook is better 
but still gives too much in certain ways.  Both organizations have received enough publicity
around these issues that you would think they would have fixed them (Facebook has in many
instances).  I'm not sure that more pressure would improve the situation.  I feel that the
storage of the users half of the oauth tokens in the client mitigate the largest part of the
risk (having a honey pot on the server).

As replacements for OAuth, there is no viable replacement. When
extensibility for the share is available, some 3rd parties may choose to use non-OAuth api's, 
however I do not see the major social networks doing so.  Even small networks such as OStatus
is using OAuth.

Pie in the Sky;   We should create something OAuth-like that does not have the specific issues 
of OAuth, but it could take significant effort and time to get 3rd party providers to adopt new 
protocols.  

- shanec|mixedpuppy

Just because OAuth is the only immediately available technology for deployment, doesn't
mean we should use it.  We should not trade user privacy for a few more months of 
deployment, and I think in this case there are alternatives we can and should explore.
We lead by example: we make things better.  It's not sufficient in this case to settle
for a privacy-invasive implementation because it's how other services do it. We should
innovate and show others how to do it right.  

- Sid

Browsing History

A subset of the user's browsing history (exposed to Mozilla and third party services). This is done through the UI and functionality that F1 makes available.

The Risk: the user will, knowingly, provide third parties with insight into what sites they've visited in the past. Browsing history is generally considered to be private, and the disclosure of such data should be calculated. This is a very tiny risk since the whole point of the feature is to share URLs. Nonetheless, the risk is there and if this feature can be abused by web sites or accidentally shares URLs without the user's explicit consent, the users protection of their browser history is essentially compromised.

Additionally, any URLs shortened through a URL shortening service are disclosed to that service. If URL shortening is triggered automatically, a subset of the user's browsing history will be disclosed to the shortening service.

Requirement: Make it clear that the URLs are being shared. Apply appropriate security measures to make sure the sharing process is not easily automated by untrusted content. Apply appropriate opt-in measures to ensure users are aware shortened URLs are transmitted to a third party shortening service.

Screenshots

Screenshot thumbnails of visited sites via base64preview are exposed to Mozilla and third party services. On top of sharing a URL, if a screenshot or thumbnail of a site can be provided to enhance the sharing experience.

The Risk: Users may accidentally disclose private information that's available on their view of a URL that's not visible to others who access the URL. The data may include anything from their specific session, data typed in after the page was opened, anything created by the content while rendered, anything fetched with asynchronous HTTP requests. This could be as simple as their username typed in the page or as complex as messages and social connections on the site.

Recommendation: If the screenshots are high-enough resolution, make it clear that the screenshot being shared reflects the current state of the page (including anything specific to their interactions with the site being shared), and get the user's authorization to share it.

Conformity to Private Browsing Mode (if Applicable)

Since sharing is an explicitly user-initiated action (like bookmarking), it will remain available during private browsing mode.

Recommendation: During a private browsing session, any data automatically obtained (and stored in the chrome component's storage API) should be kept in volatile memory only. This is data that the user doesn't explicitly ask for, such as automatically synced contacts. New account setup data and other data explicitly requested by the user to be stored should be kept as we do with sync. This data stored in memory from the private mode session should be erased when private mode is exited.

Alignment with Privacy Operating Principles

See Also: Privacy/Roadmap_2011#Operating_Principles:

Principle: Transparency / No Surprises: It's pretty clear that F1 is sharing a URL with a third party service, and the UI seems to clearly explain with whom.

Recommendations: none

Principle: Real Choice: F1 doesn't intentionally retain data.

Requirements: Make it clear when enabling the feature that you will be authorizing Mozilla to access accounts on your behalf.

Principle: Sensible Defaults: F1 is off by default.

Recommendations: none

Principle: Limited Data: F1 doesn't retain much data at all on the servers. As designed, the Sharing Service has complete OAuth-based access to all your accounts.

Requirements: Brainstorm alternative directions and ways to avoid obtaining OAuth tokens to perform sharing; ideally, authentication/sharing could be performed without our servers as a proxy, minimizing risk.

Follow-up Tasks and tracking

What	Who	Bug	Details
[DONE] Discuss Recommendations	Sid & Shane		Meeting: 27-April-2011 at 1:30 PDT
[NEW] Discuss architecture and privacy risk with large group	?		Meeting TBD
[NEW] Figure out how to share without Mozilla having complete access to users' accounts	?		TBD