Data Safety

DRAFT

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.

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

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

Data Safety Policy & Process

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 work to let people leave and take their data with them, and we'll always explain what benefit you get from this data collection.

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. 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.
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.

Key Considerations for Data Safety at Mozilla

This section provides a series of considerations for teams working with personal data about our users. We encourage everyone at Mozilla to not only uphold with these values, but also to actively seeks ways to think about ways to embed them into our myriad products, services, and activities.

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 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:

1. Client-Side
2. End-to-End Encryption
3. 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:

	Data Architectures
	Client-Side	End-to-End Encryption	Hosted/Cloud
Required Actions	No data stored by Mozilla; User controlled	Data stored by Mozilla; Not readable; User controlled	Data stored by Mozilla and/or in cloud environment; Under Mozilla's control
Data Safety Approval	N	N	Y
Security Review	Y	Y	Y
Privacy Review	Y	Y	Y
Legal Review	Y	Y	Y

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
• 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

Experimental & Research Activities

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 prior to a full product release
• User data is not combined / cross-referenced / 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 easy 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

Engagement & Marketing Activities

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.

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. However, Engagement is required to bring an engagement or marketing activity in for a consultation under three circumstances:

1. Proposed engagement activity connects to and/or utilizes user data from one of Mozilla's products, services or related features
2. Proposed activity leads to the creation of a standalone product that generates new sources of user data
3. Proposed campaign contemplates linking and/or utilizing user data from non-Mozilla, externally-created data sources

Scheduling a Consultation

The Data Safety Team holds consolations on a preset date each month.

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 use the following template in preparing for a presentation to the Data Safety Team: Data Safety Consultation Template

Consultation Archive

Coming soon...

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 infrastructure security, overseeing 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.