Privacy/Reviews/F1
Contents
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 |
