Document Overview

Timeline:

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:

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: https://wiki.mozilla.org/Features/Thunderbird/BigFiles

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

Components

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.

YouSendIt Provider

This component implements the nsIMsgCloudFileProvider interface.

Stored Data:

Dropbox Provider

This component implements the nsIMsgCloudFileProvider interface.

Stored Data:

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.

Eavesdropping

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.

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.

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).

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