Privacy/Reviews/PhonebookAPI
Contents
Document Overview
Feature/Product: | Phonebook API |
Projected Feature Freeze Date: | tbd |
Product Champions: | Aakash Desai, Jishnu Menon, James Socol |
Privacy Champions: | David Dahl |
Security Contact: | Curtis Koenig |
Document State: | [ON TRACK] Responses and Verification needed |
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
- TastyPie API: Offers Paid Staff to GET from the Mozillians' Phonebook API. Currently, we only allow users to get information for irc nickname and display name, but will also include e-mail address, groups and location (by country, state/province and/or city).
Phonebook API
Stored Data:
What | Where |
---|---|
app database | |
display_name | app database |
ircname | app database |
website | app database |
groups | app database |
skills | app database |
country | app database |
region | app database |
city | app database |
Communication with Community Site/Tool (ex. Exact Target)
- Vouched Mozillian Authorization
Direction | Message | Data | Notes |
---|---|---|---|
In: | N/A | query including e-mail address | |
Out: | N/A | is_vouched status of e-mail address |
- Sharing of Mozillian E-mails
Direction | Message | Data | Notes |
---|---|---|---|
In: | message 1 | query including specified group(s), skills or country/region/city | |
Out: | message 2 | Blob of e-mail addresses corresponding to message |
- Sharing Mozillian profile data
Direction | Message | Data | Notes |
---|---|---|---|
In: | message 1 | query including specified e-mail address | |
Out: | message 2 | Blob of Mozillian profile data: display_name, ircname, country/region/city, groups, skills, website |
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
Contributors give explicit consent by opting-in for profile sharing when they register for the service. They need to be able to see how the data is being used.
Recommendations: It would also be helpful to show the user how their data is being shared/used via the api -- perhaps by sending them a message when a new site access the API (including a list of sites accessing their data through the api).
Principle: Real Choice
Users have an opportunity to opt-in at registration, but should have control if they change their minds later.
Recommendations: Expose an option in the user's "edit profile" screen to allow them control over whether their data is exposed via the API.
Principle: Sensible Defaults
- the sensible default action will be no sharing of profile data, which is good.
Recommendations:
- none
Principle: Limited Data
- As all users must be logged in and vouched by other Mozillians to view profile data that is more than beyond name. This limits web/data scrapers from collecting these profiles.
Recommendations:
- none
Follow-up Tasks and tracking
What | Who | Bug | Details |
---|---|---|---|
[NEW] Initial Overview Discussion | ? | Meeting time TBD |