Data Safety: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
DRAFT
This page is edited by members of the Data Safety Team. Please don't change without permission.
To offer new product and service offerings that are in the interest of our 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.
We strive to define an approach to Mozilla's handling of user data that's different from the industry norm. We believe it must put people at the center and that our approach should be to store user data 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 let people leave and take their data with them, where that's feasible, and we'll always explain what benefit you get from this data collection.
This site provides information on Mozilla's Data Safety requirements, process and past activities. We welcome feedback and collaboration, in blogs, on dev.planning, or on Twitter with the hashtag #mozdatasafety.
= Data Safety Policy & Process =
== Policy ==
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 in a readable format 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 render currently unreadable user data readable to Mozilla are also required to adhere to this process. Data Safety Consultations are not replacements for privacy and security reviews, 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:
# '''Consultations:''' The Data Safety Team works with teams to assess privacy, security and data governance implications and devise technical and operational mitigations.
# '''Community Input:''' Recommendations from the Data Safety Team will be posted to Governance for public input and discussion. Working with public contributors will be the responsibility of the proposing team to consider and incorporate into its final requirements.
# '''Approvals:''' 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 input was visceral enough to advise against moving forward with development.
= Guidance =
This section provides
== Privacy Principles ==
By extension of the Mozilla Manifesto, we have six core privacy principles that guide our data handling practices and operations. We apply these to those areas of our activities that involve collecting, using, and 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 entitled, Mozilla's Privacy and Data Operating Principles." See http://blog.mozilla.com/privacy/2011/01/12/mozillas-privacy-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 entitled, "Mozilla to Offer New User Centric Services in 2012." See http://blog.mozilla.com/privacy/2012/01/13/mozilla-to-offer-new-user-centric-services-in-2012
== Definitions ==
== Data Classification ==
= 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  ==
==  Criteria  ==



Revision as of 23:22, 16 February 2012

DRAFT This page is edited by members of the Data Safety Team. Please don't change without permission.

To offer new product and service offerings that are in the interest of our 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.

We strive to define an approach to Mozilla's handling of user data that's different from the industry norm. We believe it must put people at the center and that our approach should be to store user data 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 let people leave and take their data with them, where that's feasible, and we'll always explain what benefit you get from this data collection.

This site provides information on Mozilla's Data Safety requirements, process and past activities. We welcome feedback and collaboration, in blogs, on dev.planning, or on Twitter with the hashtag #mozdatasafety.

Data Safety Policy & Process

Policy

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 in a readable format 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 render currently unreadable user data readable to Mozilla are also required to adhere to this process. Data Safety Consultations are not replacements for privacy and security reviews, 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:

  1. Consultations: The Data Safety Team works with teams to assess privacy, security and data governance implications and devise technical and operational mitigations.
  2. Community Input: Recommendations from the Data Safety Team will be posted to Governance for public input and discussion. Working with public contributors will be the responsibility of the proposing team to consider and incorporate into its final requirements.
  3. Approvals: 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 input was visceral enough to advise against moving forward with development.

Guidance

This section provides

Privacy Principles

By extension of the Mozilla Manifesto, we have six core privacy principles that guide our data handling practices and operations. We apply these to those areas of our activities that involve collecting, using, and retaining personal data from our users, employees, and contributors.

  1. No Surprises: Only use and share information about our users for their benefit and as disclosed in our notices.
  2. 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.
  3. Sensible Settings: Establish default settings in our products and services that balance safety and user experience as appropriate for the context of the transaction.
  4. 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
  5. 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.
  6. 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 entitled, Mozilla's Privacy and Data Operating Principles." See http://blog.mozilla.com/privacy/2011/01/12/mozillas-privacy-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 entitled, "Mozilla to Offer New User Centric Services in 2012." See http://blog.mozilla.com/privacy/2012/01/13/mozilla-to-offer-new-user-centric-services-in-2012

Definitions

Data Classification

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

To ensure appropriate oversight and governance of how Mozilla collects, uses and/or retains user data in the product development lifecycle and product functionality, three key conditions apply:

No Data Safety Review is needed if your product / project has an architecture employing user-controlled key encryption without Mozilla access or where data stored on the user’s client or device is under the user’s control. If you need / want to use hosted data that can be accessed by Mozilla staff, contributors or developers, then a Data Safety review is required.

Anything we do with user data will require Security, Privacy and Legal reviews at a minimum, just as it does today. You can find more information about these reviews here:

  • Privacy Reviews
  • Security Reviews

Special Cases: Accelerated Data Safety Approval

Test