From MozillaWiki
Jump to: navigation, search

Document Overview

Feature/Product: BigFiles transfer in Thunderbird
Projected Feature Freeze Date: (tbd)
Product Champions: JB Piacentino
Privacy Champions: David Dahl
Security Contact: Curtis Koenig
Document State: [DONE]


Architectural Overview: 24-May-2012
Recommendation Meeting: N/A
Review Complete ETA: 11-June-2012


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:

Allowing users to upload large file attachments to some storage service, be it a third party like Dropbox or YouSendIt, or a private storage service (a WebDAV server behind a corporate firewall, for example).

Links to the uploaded files are then inserted into the body of the email, making it easy for the recipient to download them.

Design Documents:

The following diagram illustrates the data flow with the two included nsIMsgCloudFileProvider implementations.



Each supported storage service has a corresponding XPCOM component implementing the nsIMsgCloudFileProvider interface. These components are responsible for handling authorization, file upload, file deletion, and user profile retrieval from the service (where the user profile tells us things like how much space is left for the user to fill with their files).

A cloudFileAccounts component manages the creation and deletion of accounts, and instantiates instances of the appropriate nsIMsgCloudFileProviders when necessary.

The mail compose window calls out to the cloudFileAccounts component to determine what storage services are supported, and when requested by the user, uses cloudFileAccounts to create the appropriate nsIMsgCloudFileProvider instance, and then uploads the selected file(s) through it.

There is a pane in the Thunderbird preferences dialog that allows a user to add or delete storage accounts. We currently only allow one account per account type, but this limitation might be overcome in future versions.

BigFiles Management.png

YouSendIt Provider

This component implements the nsIMsgCloudFileProvider interface.

Stored Data:

What Where
Account username nsILoginManager
Account password (optional) nsILoginManager
Account session token nsILoginManager
Uploaded files YouSendIt servers

Dropbox Provider

This component implements the nsIMsgCloudFileProvider interface.

Stored Data:

What Where
OAuth token / secret nsILoginManager
Uploaded files Dropbox servers

User Data Risk Minimization

Conflicting privacy and security policies

Risk: third parties may not live up to the same standards as the Thunderbird implementation, and may surprise users with their privacy practices.

Requirement: We will vet the privacy and security policies of the link-providers and provide in-product links to their privacy policies and terms of use.

[DONE] Link from here to screenshot or diff of in-product links to privacy policies and terms of use. See Media:Filelink_privacy_policy_links.png


Risk: attachments may get "sniffed" in transit.

Requirement: communication channels to and from the attachment storage providers must be available in and default to HTTPS.

[RESOLVED] Upload and download streams are encrypted. See: [1] [2] [3].

File Crawling

Risk: since the files are world-readable, it may be possible for an attacker to guess the download URL of a given file.

Requirement: make sure it's reasonably hard to guess the download URLs.

[DONE] document how much entropy is in each download URL. Yousendit: 22 char hash of file contents. Ubuntu One: 22 char hash of file contents. Other providers?

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

We point the user at the privacy and terms of service of the providers. We also are requiring the providers not to expire files, so that the e-mail recipients don't end up with stale links.

Risk: A "surprise" may manifest itself is when a user mis-forwards the message to the wrong party and the file can be downloaded by an unintended recipient. This can happen with the current set-up if a user forwards an attachment to the wrong party, and is a risk inherent in email.

An added risk of this system is that the file is publicly available and not limited in accessibility to those who can access the message itself. This is like 'security by obscurity', which is not ideal, but acceptable in this case since users know the file will be uploaded to a sharing service.

Recommendation: Make it clear to users that uploaded files will be world-readable (to members of the world who know where to find it).

[DONE] Make it clear to users that uploaded files can be downloaded by anybody with the link or who can guess the link. Filed as bug 772072

Principle: Real Choice

The product provides two file link providers in the initial release, and have two more (Ubuntu One and SpiderOak) in the pipeline. The architecture is completely open so new file link providers can be added via an extension, or in product. Additionally, the use of this service is optional, and users do not need to sign up for a file-sharing service in order to use the rest of Thunderbird's functionality.

Recommendations: None.

Principle: Sensible Defaults

Initially, attached files larger than 1MB trigger a prompt that suggests the File Upload feature to users. This can be adjusted.

Risk: users may encounter this dialog more than they want and start uploading files more than necessary (especially smaller documents that should be kept more confidential.)

Recommendation: To minimize potential for unnecessary use, we should increase the trigger size to be closer to the attachment limit for most SMTP servers. 5 MB is a common attachment limit for SMTP servers.

{{ResolutionBox|[DONE] Increase trigger size from 1 MB to a larger value (5 MB). Filed asbug 772070.

Principle: Limited Data

This feature doesn't track locally the files that have uploaded to file link providers, other than in the FCC-field-copied messages (forward to self). Thunderbird doesn't persist things like quota size or disk space used.

Recommendations: None.

Follow-up Tasks and tracking

What Who Bug Details
[DONE] Initial Overview Documented Mike Conley / David Bienvenu 24-May-2012
[DONE] Risk Analysis David Dahl 31-May-2012
[DONE] Public Review dev.planning 13-June-2012
[DONE] Increase trigger size for files Mike Conley Bug 772070
[DONE] Make it clear to users that uploaded files are world-readable Mike Conley Bug 772072
[DONE] Document (on this page) how much entropy is in each provider's download URLs
[DONE] Add link from this page to screenshot or diff of in-product links to providers' privacy policies.