STATUS: [DRAFT]

Overview

Mozilla Labs exists to stretch the boundaries and explore creative and novel ideas around new features, standards, products and services that help to promote openness, innovation and opportunity on the web.

As a group focused on innovation and helping define the future of both Mozilla products, services and the web at large, our stance on privacy is two-pronged:

• First, we should actively work to improve the current state of affairs for users through innovation. This means understanding the privacy environment that normal people operate under, and considering all approaches to improving their control over their privacy, or proactively defend against anticipated threats. Can we come up with new features, or new approaches to existing features, which boost effective privacy?

• Second, we should consider privacy in our non-privacy-centric work. In particular, experimental work by definition tends to be underspecified -- if we knew the answers, we could just jump straight to product implementation. Thus many of the fairly absolute statements which Mozilla subscribes to in product and production services need to be relaxed when it comes to experimental stages of idea development. At the same time, we both need and value feedback and contributions from others. So we can't realistically answer experimental questions without user contributions and user data -- likely more user data than we'll need in a production phase.

To deal with this conflict, Labs projects need to establish a relationship with participants in experiments which is similar to the relationship between subjects in experimental trials -- clarity about the purpose of the experiment, the data being collected, who will get access to what data, etc. On the flip side, experimentalists (people running experiments) need to be educated and informed of their responsibilities regarding user data (including the consequences of abusing that trust).

A second part of the privacy model around experimental projects is that there has to be progressively deeper involvement of the operational, security & privacy teams within Mozilla as the project matures, starting before collection of data by people outside of the project team. We should strive to lay the groundwork for experimentation in such a way that experiments can be smoothly transitioned to product development, and thus more stringent requirements, or end-of-lifed in a privacy preserving fashion.

Mozilla Privacy Principles

No Surprises

Understand what data we are using in our projects and for what purpose, and ensure the user has a way to review and understands those uses. Users should understand and agree to the fact that they are using experimental software.

• for any data we collect, project documentation must include what/where/why and how.
• user interactions should be clear enough to indicate the above, and the privacy policy covering the project should likewise spell out those details

Real Choices

Participation in an experiment is the primary choice point for users in a Labs experimental context. Each experiment should have its own opt-in mechanism, and we should never assume that a user who opted in to one kind of experiment opts in to others.

If a user chooses to leave an experiment, removal of that user's data from our data stores should be painless.

Sensible Settings

Settings are the first step to requiring users have more knowledge than necessary. Our designs should limit settings that we need, should avoid presenting them to all but the most advanced (and/or curious) users, and should be clearly defined with easy to understand documentation. Designs and architecture should inherently be privacy protecting to avoid requiring preference toggling by users.

Limited Data

Data that does not fall under the scope of the experiment should not be collected. At any point in the life-cycle of an experiment we should know what type of data has been collected (e.g. data schema's), why it is necessary (what it is used for) and where it has been stored. This information should be available for review by the UDC and any interested parties.

In those circumstances where an experiment needs to collect user data, hypothesis-testing should happen based on computerized analysis, not human inspection of personal data: in other words, we should never require a human looking at an individual's user data to answer an experimental question. Tests based on aggregate data should be the norm.

User Control

Users must have the ability to discover and review data we collect, the purpose for the collection and use of that data, and have the ability to remove data from our systems and/or products. The user should also be able to easily opt-out of further data collection.

Trusted Third Parties

Many experiments are looking at new approaches for Mozilla using user data in a social context. The current state of the art (eg. large market share organizations like Google and Facebook) may not match well with our principles. Our experiments should strive to demonstrate approaches that respect user privacy and security without sacrificing functionality, helping to show a path for other organizations to grow in that direction.