Data Safety: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
(no longer accurate, redirect to the current data classification r=merwin,gdestuynder)
 
Line 1: Line 1:
'''DRAFT'''
#REDIRECT [[Security/Data_Classification]]
 
'''To offer new products that benefit users, and to realize the full potential of our mission, Mozilla may need to use, collect and retain new sources of personal data from our users at a much larger scale than we have done in the past.'''
 
This site provides information on Mozilla's Data Safety requirements, process and past activities. We welcome feedback, in blogs, on public Mozilla newsgroups, via the Mozilla Privacy & Data Blog and on Twitter with the hashtag #mozdatasafety.
 
This page is edited by members of the Data Safety Team.
{{DoNotEdit}}
 
= Data Safety Scope & Process =
 
We strive to define an approach to user data safety that is markedly different than the industry norm. We believe users should be at the center of all data exchanges, and that we should store user data only when there is a measurable benefit to the user.
 
Mozilla's offerings must embody the values of the Mozilla Manifesto and our Privacy Principles. We won’t sell or give away user data. We'll always explain what data we store and why we store it. We'll always work to let people leave and take their data with them, and we'll always explain what benefit users get from this data collection.
 
== Scope ==
 
Data Safety aims to address the internal and external concerns of increased user data collection, use and storage by Mozilla through a purposeful and thoughtful approach. We require that all proposals for new offerings that entail storage of personal data on Mozilla servers undertake a Data Safety Consultation and are approved by the project. Modifications to existing offerings that would either start storing user data or would change the safety properties of currently stored user data are also required to adhere to this process. Data Safety Consultations will be coordinated with, but will not replace, privacy and security audits, which will still be required once teams move into development phases for their offerings or modifications.
 
Mozilla has created a Data Safety Team comprised of experts in engineering, operations, privacy, security, cryptography, and legal to lead the Data Safety Consultations and make recommendations that uphold our values and help to mitigate both organizational and user risks associated with personal data.
 
== Process ==
 
The Data Safety process consists of three components:
 
# '''Consultation:''' The Data Safety Team works with teams to assess privacy, security and data governance implications and devise technical and operational mitigations.
# '''Input:''' Recommendations from the Data Safety Team will be posted to Governance for public input and discussion. In addition to the post to Governance, working with public contributors across various open channels will be the responsibility of the proposing team to initiate, consider and incorporate into its final design specs.
# '''Approval:''' The Data Safety Team will take the outputs from the consultation and public input into account to make a final approval for a team to move forward with development.
 
Note that in some cases, the Data Safety and proposing teams may determine that no suitable alternatives exist to handling user data and/or public feedback was visceral enough to advise against moving forward with development.
 
= Key Considerations for Data Safety at Mozilla =
 
This section provides key considerations when working with user data. We encourage everyone within the Mozilla Project to uphold these values and to actively seek to embed them into our products, services, and activities.
 
== Privacy Principles ==
 
By extension of the Mozilla Manifesto, we have six core privacy principles that guide our handling of data. We apply these to any activity that involves collecting, using, or retaining personal data from our users, employees, and contributors.
 
# '''No Surprises:''' Only use and share information about our users for their benefit and as disclosed in our notices.
# '''Real Choices:''' Give our users actionable and informed choices by informing and educating at the point of collection and providing a choice to opt-out whenever possible.
# '''Sensible Settings:''' Establish default settings in our products and services that balance safety and user experience as appropriate for the context of the transaction.
# '''Limited Data:''' Collect and retain the least amount of information necessary for the feature or task. Try to share anonymous aggregate data whenever possible, and then only when it benefits the web, users, or developers
# '''User Control:''' Do not disclose personal user information without the user’s consent. Advocate, develop and innovate for privacy enhancements that put people in control over their information and online experiences.
# '''Trusted Third Parties:''' Make privacy a key factor in selecting and interacting with partners.
 
For more information on how we arrived at these principles, you can read our blog post from January 12, 2011: [http://blog.mozilla.com/privacy/2011/01/12/mozillas-privacy-data-operating-principles Mozilla's Privacy and Data Operating Principles].
 
== Data Safety Design Principles ==
 
Taking our Privacy Principles down to the data governance layer, we propose a few starting design guidelines:
 
* '''Clear User Benefit:''' there should always be a clear and direct user benefit that results from the data we collect. Aggressive user data storage “just in case it’s needed later” is not acceptable.
* '''Data Inventory:''' we should always know what data we’re collecting, where and how it’s stored, and why the storage of each datapoint is crucial to the end-user feature. We should make sure users can easily get at this inventory, understand it, update it, or delete it.
* '''Minimize Server-Visible Data:''' if we can implement a given feature by never sending data to the server, or by using application-level encryption, then we will.
* '''Minimize Data Retention:''' we should store data for as little time as possible. In particular, if we need servers only to provide a transit point for data, then that data should only transit, never be stored.
* '''Aggregate Whenever Possible:''' we will explore whether we can implement the feature with data aggregated across a significant number of users, rather than keeping individual data points. (Given the richness of these datasets, we cannot pretend that de-identification is particularly useful to protecting individual users.)
 
Background on these principles is available in our January 13, 2012 blog post: [http://blog.mozilla.com/privacy/2012/01/13/mozilla-to-offer-new-user-centric-services-in-2012 Mozilla to Offer New User Centric Services in 2012].
 
== User Benefits ==
 
The top goal for this effort is to foster clear and direct user benefits as the driving force for the collection and storage of data. A direct user benefit will likely fit into one of these categories:
 
* giving users access to their data wherever they need it
* acting, when the user wants, on his or her behalf
* aggregating data to give users personalized recommendations
 
In all cases the user benefit should be clearly explained to the user.
 
Wherever data is collected, in addition to providing the feature which this data collection intends to fulfill, we should provide to the user the ability to see exactly what data was collected in raw form. This provides an additional user benefit: greater transparency into data collection practices.
 
== Defining User Data ==
 
; User Data : Data about an individual that may be comprised of two types of non-mutually exclusive categories: <br>
1) Identifiers or a data element that can single out a particular individual (e.g., name, email address or fingerprint); and <br>
2) Attributes or characteristics about a particular person (e.g., browsing habits, gender, or green eyes) that may be identifiable (e.g., raw data from the user) or anonymous (e.g., browser type, OS, aggregate usage data).
 
== Data Classification ==
 
Coming soon...
 
= Preparing for a Data Safety Consultation =
 
This section describes when a Mozilla team is required to meet with the Data Safety Team and seek approval of an idea or design for a new product or service offering that utilizes user data.
 
==  Criteria  ==
 
Not everything Mozilla does with personal data requires consultation and approval from the Data Safety Team before being developed. It's important for product and engineering teams to consider various data architectures and weigh the pros and cons associated with those models.
 
Based on existing models, expertise and input from across the Mozilla community, there are primarily three data architectures that we utilize as an organization:
 
# Client-Side
# End-to-End Encryption
# Hosted/Cloud
 
For teams utilizing either client-side or end-to-end encryption as their architecture for user data, there is no requirement to work with the Data Safety Team. Both of these approaches facilitate direct user control over their personal data and reduce Mozilla's security, privacy and legal requirements to safeguard this data. For teams that need to use hosted user data either on Mozilla servers or via a contracted hosting provider and that is accessible by Mozilla staff, contributors or developers, then prior consultation and approval is required.
 
The following table highlights the criteria and review requirements by each data architecture:
 
<table style="border-color: #000000; border-width: 1px; border-style: solid; width: 80%;" border="0" cellspacing="0" cellpadding="0" align="left">
<tr>
<td>&nbsp;</td>
<td style="text-align: center;" colspan="3"><strong>Data Architectures</strong></td>
</tr>
<tr>
<td style="width: 15%">&nbsp;</td>
<td style="text-align: center; width: 20%">Client-Side</td>
<td style="text-align: center; width: 20%">End-to-End Encryption</td>
<td style="text-align: center; width: 20%">Hosted/Cloud</td>
</tr>
<tr>
<td><font color="navy"><strong>Required<BR>Actions</strong></font></td>
<td><center><i>No data stored by Mozilla; User controlled</i></center></td>
<td><center><i>Data stored by Mozilla; Not readable; User controlled</i></center></td>
<td><center><i>Data stored by Mozilla and/or in cloud; Mozilla controlled</i></center></td>
</tr>
<tr>
<td><font color="navy">Data Safety Approval</font></td>
<td style="text-align: center;">N</td>
<td style="text-align: center;">N</td>
<td style="text-align: center;"><B>** Y **</B></td>
</tr>
<tr>
<td><font color="navy">Security Review</font></td>
<td style="text-align: center;">Y</td>
<td style="text-align: center;">Y</td>
<td style="text-align: center;">Y</td>
</tr>
<tr>
<td><font color="navy">Privacy Review</font></td>
<td style="text-align: center;">Y</td>
<td style="text-align: center;">Y</td>
<td style="text-align: center;">Y</td>
</tr>
<tr>
<td><font color="navy">Legal Review</font></td>
<td style="text-align: center;">Y</td>
<td style="text-align: center;">Y</td>
<td style="text-align: center;">Y</td>
</tr>
</table>
<BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR>
 
Note that everything Mozilla does with personal data requires Security and Privacy reviews to be conducted during the development lifecycle. You can find more information about these reviews here:
 
* [[Privacy/Reviews|Privacy Reviews]]
* [[Security/Reviews|Security Reviews]]
 
== Special Cases: Accelerated Data Safety Approval ==
 
Data Safety approval related to the following areas is dependent on the circumstances for each project. Approvals may require additional consideration and/or may be granted as an exception to the usual conditions in the following two areas.
 
* Experimental & Research Activities
* Engagement & Marketing Activities
 
<b>Experimental & Research Activities</b>
 
For experimental research-related activities, teams can forgo approval if systems with access to user data run on the upcoming Petri system, and require opt-in by users. The following requirements must also apply:
* No sensitive personal data is collected or used
* There is a limited and defined data retention period
* Notice is sent to users if an experimental offering moves to a production release and choice provided to have data migrated to the new system
* User data is not combined, cross-referenced, or triangulated with other user data from other research or experimental systems
 
Project Petri is a 1-year experiment in providing an Infrastructure-as-a-Service offering to make it easier for Mozilla teams with new ideas for web apps to try them quickly, with minimal impact on IT/Ops, and with an on-ramp to making web apps that are better/safer/faster/more maintainable if the ideas they're testing prove to be useful. For more info, see https://wiki.mozilla.org/Petri
 
<b>Engagement & Marketing Activities</b>
 
Engagement-sponsored marketing activities, projects and campaigns that entail the collection, use and retention of personal data are held to the same privacy and data principles as our products and services. Mozilla's Engagement team has dedicated privacy professionals, Privacy Friends and legal contributors who review and support all of its activities in alignment with Mozilla's principles.
 
Engagement is required to bring an engagement or marketing activity in for a Data Safety consultation under three circumstances:
 
# Proposed engagement activity connects to and/or utilizes user data from one of Mozilla's products, services or related features
# Proposed activity leads to the creation of a standalone product that generates new sources of user data
# Proposed campaign contemplates linking and/or utilizing user data from non-Mozilla, externally-created data sources
 
Day-to-day marketing tasks do not require a Data Safety Consultation, including data handling practices associated with our newsletters, online surveys, advertising, social media and contests.
 
== Scheduling a Consultation ==
 
The Data Safety Team currently holds monthly consultations. (The frequency of consultations may increase depending on number of teams/projects that require review.)
 
{| class="querytable" align="center" style="width:38%; font-size:90%"
|+'''Planned Consultation Dates'''
|-
! style="background:#dcdcdc;" | Date
! style="background:#efefef;" | Time
|-
| Tue, 14 Feb 2012 || 9.00 - 10.00AM
|-
| Thu, 15 Mar 2012 || Noon - 1.30PM
|-
| Wed, 25 Apr 2012 || 1.30 - 3.00PM
|-
| Wed, 16 May 2012 || 1.30 - 3.00PM
|}
 
''All meeting times are Pacific Standard Time.''
 
Teams are asked to provide background information ahead of the meeting and then given 30 minutes to present their proposals.
 
Input is provided during the meeting and contributors on the Data Safety Team commit to work with presenting teams to resolve open questions about user data, privacy and security following the team's presentation.
 
To get your team on the agenda for an upcoming Data Safety Consultation, please contact Alina Hua.
 
== Template ==
 
Please refer to the following template in preparing for a presentation to the Data Safety Team:
[[Data Safety/Data Safety Consultation Template|Data Safety Consultation Template]]
 
== Consultation Log and Archive ==
 
=== Scheduled / Active Reviews ===
Meeting notes for each project / team under review can be accessed through the available links in the tables below. For the full list of meeting notes, see the Meeting Notes section below.
 
{| class="sortable fullwidth-table" style="font-size:90%"
|-
| style="background:#D8D8D8; width:28%" | '''Project / Team'''
| style="background:#D8D8D8; width:39%" | '''Status'''
| style="background:#D8D8D8; width:17%" | '''Team Contact'''
| style="background:#D8D8D8; width:16%" | '''Review Date'''
|-
| Lovebomb || Reviewed by partial Data Safety Team (DST). Additional input pending from DST members. || Ben Simon || 2012-03-15
|-
| Betafarm || Reviewed by partial Data Safety Team (DST). Additional input pending from DST members. || Ben Sternthal || 2012-03-15
|-
| Push Notifications || Reviewed by partial Data Safety Team (DST). Additional input pending from DST members. || JC Conlin, Mike Connor, Jeff Balogh || 2012-03-15
|-
| [[Data Safety/Data Safety Consultation Meeting Notes/2012-02-14|Open Badges Infrastructure (OBI)]] || Follow-up discussion scheduled for 08 Mar 2012 || Brian Brennan || 2012-02-14
|-
| [[Data Safety/Data Safety Consultation Meeting Notes/2012-02-14|Mozilla Marketplace]] || Additional documentation requested || Justin Scott || 2012-02-14 
|}
 
=== Past Reviews ===
 
{| class="sortable fullwidth-table" style="font-size:90%"
|-
| style="background:#D8D8D8; width:28%" | '''Project / Team'''
| style="background:#D8D8D8; width:39%" | '''Status'''
| style="background:#D8D8D8; width:17%" | '''Team Contact'''
| style="background:#D8D8D8; width:16%" | '''Review Date'''
|-
| Pancake || Follow-up meeting with team on Fri, 2011-03-23 || Stuart Parmenter || 2011-11-11
|-
| [[Data Safety/Data Safety Consultation Meeting Notes/2011-10-28|BrowserID]] || Review again when features evolve.  || Ben Adida || 2011-10-28
|-
| [[Data Safety/Data Safety Consultation Meeting Notes/2011-09-28|Metrics Ping]] || In progress || Gilbert FitzGerald || 2011-09-28
|}
 
=== Meeting Notes ===
 
See [[Data_Safety/Data Safety Consultation Meeting Notes|Data Safety Consultation Meeting Notes]] for agendas, meeting minutes and project documentation.
 
== Contributors ==
 
The following people have come together to form a Mozilla Data Safety Team to develop these ideas and bring them into our product offerings:
 
* Jay Sullivan, who leads the definition of great Mozilla products that embody our values
* Sid Stamm, who leads engineering for privacy in Firefox and the web platform
* Jonathan Nightingale, who runs the Firefox engineering group
* Alex Fowler, who leads privacy and policy and focuses on enhancing information management
* Brendan Eich, who has led from day one the technical direction of the Mozilla Project
* Michael Coates, who leads security assurance, overseeing security for Firefox, Mozilla web applications, servers, & networks
* Chris Beard, who leads our marketing and engagement programs
* David Ascher, who leads Mozilla’s thinking on how users share and discover the Web
* Ben Adida, who leads the Identity work at Mozilla
 
Supporting the work of the Data Safety Team and all those who interact with it are:
 
* Alina Hua, Manager, Data Governance and Privacy
* Jishnu Menon, Data and Product Counsel
* Tom Lowenthal, Privacy Analyst
 
We plan to grow this team of contributors to include individuals with more diverse backgrounds, people from inside and outside the Mozilla Project, and people from around the world.

Latest revision as of 20:51, 13 December 2016

Redirect to:

Retrieved from "https://wiki.allizom.org/index.php?title=Data_Safety&oldid=1156966"