Privacy/Reviews/ThunderbirdBigFiles: Difference between revisions
| 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: | '''The main objective of this feature/product is: | ||
* store large file attachments in online storage | |||
* providers are XPCOM components | |||
* 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, possibly also from the attachment box afterwards. | |||
* "provision" UI | |||
* "logging in" UI | |||
* "attachment" UI | |||
* receiving a mail would have a link with some annotations created by Thunderbird. | |||
'''Design Documents''': | '''Design Documents''': | ||
https://wiki.mozilla.org/Features/Thunderbird/BigFiles | |||
== Components == | == Components == | ||
Each big file provider is a 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. | |||
=== Component X === | === Component X === | ||
| Line 75: | Line 84: | ||
| | | | ||
|} | |} | ||
= User Data Risk Minimization = | = User Data Risk Minimization = | ||
Revision as of 15:46, 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
- providers are XPCOM components
- 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, possibly also from the attachment box afterwards.
- "provision" UI
- "logging in" UI
- "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 a 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.
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 |