Privacy/Reviews/PhonebookAPI: 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:''' safely share Mozillian data inputted into Mozillians.org to community sites and Mozilla paid staff. The purpose is to allow contributors greater access to getting involved into our community, while making their path to contribution easier and more seamless. | ||
There are two major use cases we're trying to solve: | |||
* When contributors go to a mozilla.org property with a profiling system, they should be offered a way to auto-populate the profiles fields with information already placed onto Mozillians.org. Contributors will need to opt-in to use the service during registration or as a logged-in user. | |||
* For mozilla.org properties, they should be able to use to grab contributor information on a per user, per group or per location basis. | |||
'''Design Documents''': | '''Design Documents''': | ||
* [http://www.flickr.com/photos/aakashhdesai/6894222294 Flow Diagram] | |||
== Components == | == Components == | ||
* API Key Generator: | |||
* TastyPie API: | |||
=== Component X === | === Component X === | ||
| Line 75: | Line 82: | ||
| | | | ||
|} | |} | ||
= User Data Risk Minimization = | = User Data Risk Minimization = | ||
Revision as of 21:15, 9 July 2012
Document Overview
| Feature/Product: | Phonebook API |
| Projected Feature Freeze Date: | tbd |
| Product Champions: | Aakash Desai, Jishnu Menon, James Socol |
| Privacy Champions: | (the privacy Friend you're working with) |
| Security Contact: | Curtis Koenig |
| Document State: | [NEW] template created |
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: safely share Mozillian data inputted into Mozillians.org to community sites and Mozilla paid staff. The purpose is to allow contributors greater access to getting involved into our community, while making their path to contribution easier and more seamless.
There are two major use cases we're trying to solve:
- When contributors go to a mozilla.org property with a profiling system, they should be offered a way to auto-populate the profiles fields with information already placed onto Mozillians.org. Contributors will need to opt-in to use the service during registration or as a logged-in user.
- For mozilla.org properties, they should be able to use to grab contributor information on a per user, per group or per location basis.
Design Documents:
Components
- API Key Generator:
- TastyPie API:
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 |