Data Safety

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

Charter

Privacy Principles

Six core privacy principles guide our data practices and operations. These principles stem from the Mozilla Manifesto.

• 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, "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 are included in our January 13, 2012 blog post entitled, "to Offer New User Centric Services in 2012."