Privacy/Reviews/ThunderbirdBigFiles: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
 
(49 intermediate revisions by 5 users not shown)
Line 6: Line 6:
|'''Projected Feature Freeze Date:''' || <section begin='eta' />(tbd)<section end='eta' />
|'''Projected Feature Freeze Date:''' || <section begin='eta' />(tbd)<section end='eta' />
|-
|-
|'''Product Champions:''' || (JB Piacentino)
|'''Product Champions:''' || JB Piacentino
|-
|-
|'''Privacy Champions:''' || (David Bienvenu)
|'''Privacy Champions:''' || David Dahl
|-
|-
|'''Security Contact:''' || (the security Friend you're working with)
|'''Security Contact:''' || Curtis Koenig
|-
|-
|'''Document State:''' || <section begin='status'/>{{new|}}<section end='status'/>
|'''Document State:''' || <section begin='status'/>{{done|}}<section end='status'/>
|}
|}


Line 19: Line 19:


{|
{|
|'''Architectural Overview:''' || (date TBD)
|'''Architectural Overview:''' || 24-May-2012
|-
|-
|'''Recommendation Meeting:''' || (date TBD)
|'''Recommendation Meeting:''' || N/A
|-
|-
|'''Review Complete ETA:''' || <section begin='revieweta' />tbd<section end='revieweta' />
|'''Review Complete ETA:''' || <section begin='revieweta' />11-June-2012<section end='revieweta' />
|}
|}


Line 30: Line 30:
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.  
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:''' (describe the goals of the feature/product here)
'''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''':  
'''Design Documents''':  
Link to any design or architectural documents here.
https://wiki.mozilla.org/Features/Thunderbird/BigFiles


The following diagram illustrates the data flow with the two included nsIMsgCloudFileProvider implementations.
[[File:BigFiles.png|500px]]
== Components  ==
== 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.
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.


=== Component X  ===
[[File:BigFiles_Management.png]]


This component does A, B and C and interacts with component Y to do D.
=== YouSendIt Provider ===


The tables below simply summarize the data encountered by this component.  
This component implements the nsIMsgCloudFileProvider interface.


'''Stored Data:'''  
'''Stored Data:'''  
Line 52: Line 65:
! Where
! Where
|-
|-
| data type
| Account username
| where stored
| nsILoginManager
|-
| Account password (optional)
| nsILoginManager
|-
| Account session token
| nsILoginManager
|-
| Uploaded files
| YouSendIt servers
|}
|}


'''Communication with Component Y'''  
=== Dropbox Provider ===
 
This component implements the nsIMsgCloudFileProvider interface.
 
'''Stored Data:'''  


{| class="wikitable"
{| class="wikitable"
|-
|-
! Direction
! What
! Message
! Where
! Data
! Notes
|-
|-
| ''In:''
| OAuth token / secret
| message 1
| nsILoginManager
| types of data received from component Y with the message
|  
|-
|-
| ''Out:''
| Uploaded files
| message 2
| Dropbox servers
| types of data sent to component Y with the message
|  
|}
|}


= 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.
{{ResolutionBox|{{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]]}}}}
=== 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.
{{ResolutionBox|{{resolved|Upload and download streams are encrypted. See: [http://mxr.mozilla.org/comm-central/source/mail/components/cloudfile/nsYouSendIt.js#18] [http://mxr.mozilla.org/comm-central/source/mail/components/cloudfile/nsDropbox.js#33] [http://mxr.mozilla.org/comm-central/source/mail/components/cloudfile/nsUbuntuOne.js#30].}}}}


= User Data Risk Minimization =
=== 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.


In this section, the privacy champion will identify areas of user data risk and recommendations for minimizing the risk.
{{ResolutionBox|{{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 =
= Alignment with Privacy Operating Principles =
Line 88: Line 129:


====Principle: Transparency / No Surprises====
====Principle: Transparency / No Surprises====
(How the feature addresses this)
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.


''Recommendations'': (what can be improved)
''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).
{{ResolutionBox|{{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====
====Principle: Real Choice====


''Recommendations'':
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====
====Principle: Sensible Defaults====
Initially, attached files larger than 1MB trigger a prompt that suggests the File Upload feature to users.  This can be adjusted.


''Recommendations'':
''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 as{{bug|772070}}}}.


====Principle: Limited Data====
====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'':
''Recommendations'':
None.


= Follow-up Tasks and tracking =
= Follow-up Tasks and tracking =
Line 115: Line 170:
! Details
! Details
|-
|-
| {{new|Initial Overview Discussion}}
| {{done|Initial Overview Documented}}
| ?
| Mike Conley / David Bienvenu
|  
|  
| Meeting time TBD
| 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
| [https://bugzilla.mozilla.org/show_bug.cgi?id=772070 Bug 772070]
|
|-
| {{done|Make it clear to users that uploaded files are world-readable}}
| Mike Conley
| [https://bugzilla.mozilla.org/show_bug.cgi?id=772072 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.}}
|
|
|
|}
|}




[[Category:Privacy/Reviews|Template]]
[[Category:Privacy/Reviews|ThunderbirdBigFiles]]

Latest revision as of 15:53, 27 August 2012

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]


Timeline:

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

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.

BigFiles.png

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.

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.

Resolution:
[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

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.

Resolution:
[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.

Resolution:
[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).

Resolution:
[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.
Retrieved from "https://wiki.mozilla.org/index.php?title=Privacy/Reviews/ThunderbirdBigFiles&oldid=464414"