Data Safety

DRAFT This page is edited by afowler. Please don't change without permission.

Charter

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

Preparing for a Data Safety Consultation

This section describes when a Mozilla team is required to meet with the Data Safety Team.

Template

Please use the following template in preparing for a presentation to the Data Safety Team. [Data_Safety_Consultation_Template]