Privacy/Reviews/ThunderbirdBigFiles: Difference between revisions
| Line 32: | Line 32: | ||
'''The main objective of this feature/product is: | '''The main objective of this feature/product is: | ||
* store large file attachments in online storage | * store large file attachments in online storage | ||
* cooperating with service providers on both a technical and business side | * cooperating with service providers on both a technical and business side | ||
* can be pulblic services or private (ie. local ftp) | * can be pulblic services or private (ie. local ftp) | ||
* Files are uploaded when you attach them, | * Files are uploaded when you attach them, and normal attachments can be converted to online attachments from the compose window attachment pane. | ||
* "attachment" UI | * "attachment" UI | ||
* receiving a mail would have a link with some annotations created by Thunderbird. | * receiving a mail would have a link with some annotations created by Thunderbird. | ||
| Line 46: | Line 43: | ||
== Components == | == Components == | ||
Each big file provider is | Each big file provider is an XPCOM component. The mail compose code uses the nsIMsgCloudFileProvider.idl interface to talk to the big file provider. The big file providers then use their own API to talk to their servers. This communication is specific to each provider. The general flow is authentication of the user, followed by uploading of file contents, and retrieval of a link to the shared file. This link is then included in the e-mail sent to the mail recipients. | ||
There is also UI to provision accounts, and UI to control account settings. This UI is specific to each provider. | |||
=== Component X === | === Component X === | ||
Revision as of 15:53, 29 March 2012
Document Overview
| Feature/Product: | BigFiles transfer in Thunderbird |
| Projected Feature Freeze Date: | (tbd) |
| Product Champions: | (JB Piacentino) |
| Privacy Champions: | (Privacy Friend you're working with) |
| Security Contact: | (the security Friend you're working with) |
| Document State: | [NEW] |
Timeline:
| Architectural Overview: | (date TBD) |
| Recommendation Meeting: | (date TBD) |
| Review Complete ETA: | 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/product is:
- store large file attachments in online storage
- cooperating with service providers on both a technical and business side
- can be pulblic services or private (ie. local ftp)
- Files are uploaded when you attach them, and normal attachments can be converted to online attachments from the compose window attachment pane.
- "attachment" UI
- receiving a mail would have a link with some annotations created by Thunderbird.
Design Documents:
https://wiki.mozilla.org/Features/Thunderbird/BigFiles
Components
Each big file provider is an XPCOM component. The mail compose code uses the nsIMsgCloudFileProvider.idl interface to talk to the big file provider. The big file providers then use their own API to talk to their servers. This communication is specific to each provider. The general flow is authentication of the user, followed by uploading of file contents, and retrieval of a link to the shared file. This link is then included in the e-mail sent to the mail recipients.
There is also UI to provision accounts, and UI to control account settings. This UI is specific to each provider.
Component X
This component does A, B and C and interacts with component Y to do D.
The tables below simply summarize the data encountered by this component.
Stored Data:
| What | Where |
|---|---|
| data type | where stored |
Communication with Component Y
| Direction | Message | Data | Notes |
|---|---|---|---|
| In: | message 1 | types of data received from component Y with the message | |
| Out: | message 2 | types of data sent to component Y with the message |
User Data Risk Minimization
In this section, the privacy champion will identify areas of user data risk and recommendations for minimizing the risk.
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
(How the feature addresses this)
Recommendations: (what can be improved)
Principle: Real Choice
Recommendations:
Principle: Sensible Defaults
Recommendations:
Principle: Limited Data
Recommendations:
Follow-up Tasks and tracking
| What | Who | Bug | Details |
|---|---|---|---|
| [NEW] Initial Overview Discussion | ? | Meeting time TBD |