Congratulations, Chrome Users

Alex Fowler

We’re glad to see that Google has taken the next step in their commitment to Do Not Track.

Now that all the major browsers have their DNT implementations well underway, it’s time for advertisers and publishers to do their part, including Google’s own ad folks. While some publishers like Twitter and the Associated Press respect users with DNT enabled, and many independent ad tech companies have done so, as well, there is not yet widespread support. Everyone will soon be able to express their tracking preference, so we eagerly look forward to the day when people can trust that their privacy choices will be honored as they browse the Web.

It’s also noteworthy that Google and Microsoft have decided to implement their own user interfaces for Do Not Track. Mozilla is currently working on the second release of Do Not Track within Firefox, and we remain the only mobile browser to support it. With all these different UI experiments, users have many good options for privacy in their browser of choice and we’ll be able to more quickly determine which approaches best meet users’ expectations.

Alex Fowler

Do Not Track: It’s the user’s voice that matters

Alex Fowler

Today, Microsoft announced a change in how it will be implementing Do Not Track (DNT) in Internet Explorer. In a pre-release version of IE10, Microsoft will automatically start sending a DNT header on behalf of its users to not be tracked by third parties across the Web.

We appreciate seeing Microsoft putting its full weight behind DNT, especially given Firefox was the lone browser supporting DNT just one year ago. This will make DNT more mainstream and bring more attention to the important issue of user control.

We look forward to learning more about Microsoft’s new DNT implementation, as well as its implications for the standards work currently underway. And for the Web community, we thought it would be helpful to share our position, as well as the consensus view of the W3C Tracking Protection Group, about how we believe DNT can be most effective.

At its foundation, DNT is intended to express an individual’s choice, or preference, to not be tracked. It’s important that the signal represents a choice made by the person behind the keyboard and not the software maker, because ultimately it’s not the browser being tracked, it’s the user. In the words of the W3C group, which is made up of leading consumer privacy groups and industry representatives including Microsoft:

“Key to that notion of expression is that it must reflect the user’s preference, not the preference of some institutional or network-imposed mechanism outside the user’s control.” (Tracking Preference Expression, W3C Editor’s Draft, 29 May 2012)

DNT is not an off switch for a particular technology, rather it is the expression of an individual user’s desire being reflected in code — and that’s what makes the feature great. Do Not Track transcends specific technology and gets to the heart of what matters: how a user’s browsing habits are used.

There are three different signals to consider in broadcasting the user’s preferences for tracking:

  1. User says they accept tracking
  2. User says they reject tracking
  3. User hasn’t chosen anything

Firefox defaults to state 3: we don’t know what the user wants, so we’re not sending any signals to servers. This causes the presence of the signal to mean more — the signal being sent should be the user’s choice, not ours. Therefore, Firefox doesn’t broadcast anything until our user has told us what to send.

DNT allows for a conversation between the person sitting behind the keyboard and the site that they want to visit. If DNT is on by default, it’s not a conversation. For DNT to be effective, it must actually represent the user’s voice.

We introduced DNT to do just that: to give users a voice and let them tell sites that they don’t want to be tracked. We did this before knowing exactly how sites and advertisers would respond, and we still believe this is the most effective way for DNT to work.

Update (5-June): We’ve received a few comments asking if we believe all privacy defaults should be about letting users decide, even when that approach leaves users vulnerable. The short answer is “no”; our approach to DNT should not be viewed as a broad policy statement that will apply to other privacy and security considerations — our choice of opt-in for DNT is specific to the way the DNT feature works.

In carefully weighing our approach for appropriate DNT defaults, we talked with many members of the Mozilla community, privacy and technical experts and our users. The DNT feature relies on representing each individual’s desire to web sites, something that requires each user to activate the feature. In fact, a number of academic studies have found that there are users interested in personalized services and content, including targeted ads, so they would not like to have the header sent for them by default. Taken together, we believe the right starting point for a DNT system is a default of preference unknown.

Sid Stamm & Alex Fowler

Do Not Track Gains More Support around the Web

Alex Fowler

Mozilla introduced the Do Not Track header last year to give users more control over online tracking by third parties. Since launching Do Not Track, we have seen increased industry support and user adoption of the feature. Today, we are hosting a Do Not Track event at Internet Week New York and are happy to announce new adoption statistics and industry support.

We’re excited that Twitter now supports Do Not Track and global user adoption rates continue to increase, which signifies a big step forward for Do Not Track and the Web.

Current adoption rates of Do Not Track are 8.6% for desktop users of Firefox and 19% for Firefox Mobile users and we see the highest percentage of users turning on Do Not Track in The Netherlands, France and the United States.*

We conducted a survey of more than 10,000 Firefox users representing 140 countries and we found some interesting results. The survey showed that 49% of users surveyed believe their privacy is respected more when Do Not Track is enabled, as opposed to only 12% who feel that way without the setting. Also, the survey found users’ trust increases for browsers, publishers and advertisers who support Do Not Track. We will share more details and specific survey results soon.

We brought the industry discussion about Do Not Track to this year’s Internet Week New York to raise awareness about Do Not Track and encourage the digital media community to begin to work with it today. Speakers included Ed Felten, the Chief Technologist at the Federal Trade Commission; Brad Burnham, Partner, Union Square Ventures; Aleecia McDonald, Co-Chair, W3C Tracking Protection Group; Matt Tengler, Senior Director, Product Management, Jumptap; David Norris, CEO, Bluecava; and Colin O’Malley, CSO, Evidon.

We’re pleased to continue to see many positive steps forward for the Web as Do Not Track gains momentum and adoption.

*Mozilla does not collect or store personal information about our users to determine these statistics

Do Not Track is for Email Too

Sid Stamm

The guiding principles behind Do Not Track aren’t just for web browsers and pages. Tracking happens in a variety of ways, including through email, so we’re putting Do Not Track into Thunderbird.

Email Tracking. Sometimes email messages you receive contain external images — images that need to be loaded from the web to display the entire content of the message. This includes pixel tags and clear gifs. When your mail client renders the message, it has to go fetch the images from the web using the same technologies as a web browser. The upshot is that when the email is drawn on your screen, a web server can learn that you opened the message; this is how email tracking works. By attaching a unique ID to the URL for the image, the server can also know which specific message caused the request — including to which email address the message was sent. Email marketing organizations often use this information to track which messages you read, which links in messages you click, and then provide more customized messages in the future.

How to enable Do Not Track in Thunderbird

Thunderbird Support. A little while ago, I landed a patch that will add Do Not Track support to Thunderbird 15. While that release is a number of weeks away, if you’re using the Daily builds of Thunderbird, you’ve got the feature in Security options. This means that when you open email messages sent by marketing firms, you can enable DNT in Thunderbird to let them you don’t want to be tracked.

Next: Building Do Not Track into Thunderbird is just the first step. Next we will work with email marketing software providers to honor the DNT request. We’re reaching out to email industry leaders and introducing them to DNT and will keep you updated on what happens.

Rolling Out HTTPS Google search

Sid Stamm

23

Now in Aurora: Secure Google Searches are default. In Aurora when you search using the location bar, search box, or the right-click menu, your search will be sent to Google through a secure (HTTPS) connection. You won’t notice a difference in how you search, but your Google search suggestions and search results will be presented through a secure web site.

Enabling HTTPS for these searches shields our users from network infrastructure that may be gathering data about the users or modifying/censoring their search results. Additionally, using HTTPS helps providers like Google remove information from the referrer string. While Google users may expect Google to know what they are searching for, Firefox users may not be aware these search terms are often transmitted to sites they visit when they click on items in the search results; enabling HTTPS search helps sites like Google strip this information from the HTTP referrer string, putting the user better in control of when and to whom their interests are shared.

Encrypting our users’ searches is our next step into giving users better control over their data online. Enabling HTTPS for Google searches helps Firefox users maintain better control over who sees things they search for — queries that are often sensitive. We’re excited to see this improvement in our upcoming releases now that we, with Google’s help, have been able to provide our users a secure and responsive secure search.

Mozilla’s Identity Platform Finalist for Federal Support

Alex Fowler

Partnering with City of San Francisco and MacArthur-supported Youth Organizations to Jump Start a Vibrant Identity Ecosystem

Mozilla is one of 27 finalists selected to compete for $10 million in funding as part of the US government’s National Strategy for Trusted Identities in Cyberspace (NSTIC). Our proposal brings together the City of San Francisco and participants in the MacArthur Foundation supported Digital Media Learning Competition to use Persona, our platform for trusted identity, as the basis for establishing, supporting, and seeding demand for a federated, secure, and dynamic identity ecosystem.

Mozilla wants to help make the Web better. We want the Internet to continue to drive creativity, education, and economic growth. And we want people to understand, shape and be in control as more and more of their lives go online.

Mozilla’s proposed pilot brings together multiple partners who reflect many of the more important roles people take on in their day-to-day lives online. From citizens accessing government sites and services, to consumers buying and using apps, and for parents providing their kids with access to educational content and learning tools, we believe Persona has huge potential to improve the log-in experience for millions of people.

“Forms are, unquestionably, the most common medium of information exchange between  government and citizens,” says Jay Nath, Chief Innovation Offier for the  City & County of San Francisco. “Working within a trusted identity  framework would let citizens automatically populate forms with their  information, let us increase the number of services available online,  and even potentially allow residents to use us to vouch for their  identity to other services. There are all sorts of efficiencies to be gained.”

“We’re working, through Open Badges and other programs, to build bridges  between what kids are learning in school and out of school,” states Connie Yowell, the MacArthur Foundation’s Director of Education. “These links need to be based on a framework for secure identity that builds  parents directly into the process and empowers kids to share information  within trusted networks. Solving this problem will open up amazing  opportunities around integrated and connected learning.”

We’re excited to have the City and County of of San Francisco and a number of participants in the Digitial Media Learning Competition, funded by the MacArthur Foundation, as partners in our NSTIC proposal.

Our Vision for User-centric Identity

Mozilla’s commitment to Persona is driven by a central tenet: that the web should answer to users. Online sites, services and apps offer tremendous value and potential, but they also make it easier for vendors to invade privacy, foster poor security practices by users, and present attractive targets for fraud.

We’re building Persona to help everyone benefit from online services while mitigating risk of misuse and abuse of user data.

Persona is designed around three core principles:

  1. Individuals should be in control of their personal data;
  2. Identity should be built on open standards, cross-platform and interoperable; and
  3. Identity should be federated: a diversity of Identity Platforms (IdPs) and Relying Parties (RPs) offering direct, anonymous, and pseudonymous certifications across public, private, and non-profit sector applications.

Through this pilot, Mozilla will work to address the remaining design, technical, legal, and business process barriers to widespread adoption and growth of trusted identity.

Persona is the Ideal Platform for an NSTIC Pilot

NSTIC is the Administration’s initiative to “improve upon the passwords currently used to log-in online” and to jump start “a vibrant marketplace that allows people to choose among  multiple identity  providers – both private and public – that would issue trusted  credentials that prove identity.”

Mozilla, the City & County of San Francisco, and a consortium of major web sites serving the children’s market sponsored by the MacArthur Foundation will launch a pilot that “demonstrate[s] the feasibility of the Identity Ecosystem, via projects that link multiple sectors, including multiple Identity providers and relying parties.”

We’ll design, build, and pilot the technical architecture, business and legal framework, and public-facing functionality of integrated implementations that see people able to:

  • Support citizen-to-government interactions with the City & County of San Francisco;
  • Make app experiences seamless with support for trusted identity, tying apps directly to users, and making them available on any device; and
  • Help kids learn online with MacArthur-funded youth organizations via COPPA-compliant, trusted identity systems that increase protection for children online and make possible new and innovative learning experiences.

Mozilla’s proposal was selected out of 186 submissions. Final proposals are due in early May. We hope to be among the final five to eight organizations selected to begin work this Fall to build a standards-based identity infrastructure that is privacy preserving, trustworthy and scalable.

Zeroing in on DNT:1

Tom Lowenthal

In DC, sixty representatives from diverse groups sat together for three days this week and continued the hard work of defining a Do Not Track standard we can all live with. With contributors from the major web browser makers, many different industries, the privacy community, academia, and both the EU and US policy communities, this open process continues to be a meeting of the minds where everyone has a voice. We made great progress and it was fantastic to have so many smart people coming to consensus decisions at our fourth in-person meeting of the W3C Tracking Protection Working Group. After three days, we have two proposals with lots in common.

Tech Specs

We’re close to having a complete technical design for Do Not Track. We’re still working on a few details, but the major technical hurdles have been crossed, and very few points of disagreement remain. Here are the headlines:

  • We know how a site tells its users that it follows DNT, using a well known URI.
  • We’ve mapped out most of the JavaScript API that allows sites and users to talk about opt-ins and opt-outs.

First Parties

A first party is web content that users have meaningful interaction with. There can be multiple first parties on a page. For example, if you visit this page, you have meaningful interaction with Mozilla: we’re the place you’re trying to talk to. If we put a Facebook “Like” button on our page, Facebook would be third party unless you choose to interact with them by clicking the “Like” button. If you did, Facebook becomes a first party along with Mozilla. This approach is much better than definitions which expect only one first party per page, and require all first party webservers to have the same domain name. Best of all, it fits easily with the way that we actually use the web.

First parties don’t have to do much honor a user’s privacy request. If you go to Amazon, we assume that you’re trying to interact with them. Do Not Track will not get in the way of you seeing personalised shopping suggestions or having things shipped to your address. To have so much latitude to use data without undue constraints, Amazon just has to do two things:

  1. They have to respond and promise to follow the W3C Recommendation for Do Not Track, and
  2. they mustn’t share your data with other people, or mix it with data from other sites.

First parties can outsource data processing if they want. If a site outsourcea analytics, that’s fine. They just have to make sure their analystics company keeps data about their users separate: no mixing data from lots of sites.

Third parties

Third parties are a remarkably simple concept: anyone who isn’t a first party or a user.

Anyone, first party or third, can use data without restriction as long as they make sure that it can’t be linked to a particular user. We discussed what you might need to to do make sure that data really can’t be linked back to someone. Some of the approaches were based on k-anonymity or estimates of uniqueness based on characteristics of users who do not have Do Not Track enabled.

It’s also fine to keep server logs for a brief time before they’re rotated out and processed, but this period needs to be short, and logs mustn’t be used for anything else during this period.

We agreed there are some things like security and fraud control which are so important that even business that have no interaction with users need to be able to do them. The web is the platform and we should be careful when tinkereing with the engines that power it. We don’t want implementation of Do Not Track to harm the web, just make it safer.

Differences

Our two current proposals differ as to how “large” a party is. One proposal thinks of a party based on corporate ownership; the other makes decisions based on user expectations and branding. For many websites, this distinction makes no difference. However, for companies with many different unrelated brands this choice determines whether we think it’s more important to avoid costly implementations and restrictions for companies which currently share all their data between brands, or to avoid surprising users who have no idea how far their data can flow.

The group is split as to whether third parties can continue to use unique identifiers to enable those critical uses that are still allowed. For example, can third parties use unique identifiers to fight fraud and bill for ad impressions? How about for frequency capping to eliminate showing the same ad multiple times, even if that means knowing sites a user has visited where the ad displayed? We have more work to do here: how can we best support privacy without breaking business? We spent several hours talking through different possible approaches, from the purely technical to the purely administrative and everything in between.

At the end of the day

It’s increadibly exciting to be forging a path forward that everyone can live with. We still have work to do, and these remaining differences are not minor. But we may reach consensus decisions by coming to agreement on these two issues where we differ at the same time, and addressing them together. With all this rough consensus, we may have to start looking at some running code. Stay tuned!

Do Not Track goes mobile: Mozilla demos privacy preference at Mobile World Congress

Alex Fowler

1

As part of our week of exciting announcements for Mobile World Congress, Mozilla is demonstrating the world’s first implementation of Do Not Track for a mobile Web OS. We’re also presenting a mock-up of the new 3-state setting for Do Not Track, as envisioned by the W3C.

This comes on the heels of major announcements from the White House, the Digital Advertising Alliance and Google about growing support for the privacy feature pioneered by Mozilla to provide users more choice and control over Web tracking.

Imagining how privacy and security can be core requirements in designing a mobile platform from the ground up, our support for Do Not Track in Boot to Gecko highlights the importance of Do Not Track on mobile, as well as desktop, devices.

Why this matters

As more and more Internet users access the Web from mobile devices, a growing gap exists in users’ ability to communicate a preference not to be tracked across all the ways in which they use the Web. Gartner Research predicts that by next year more people will be accessing the Internet on their mobile devices than those who will with their desktop computers.

Mozilla was the first major browser to provide its users with Do Not Track on desktop and mobile. Firefox for Android provides users with the ability to send the DNT header to websites visited via the browser, as well as to any third parties, just like they can send the header via desktop Firefox. As of February 26th, 18% of users of Firefox for Android had turned on DNT.

However, even if all the other native browsers on mobile followed our lead, there’d still be a gap where apps installed in mobile devices that include services from third parties, like advertisers and analytics, wouldn’t see the DNT header. To ensure that these parties also see users’ preferences not to be tracked, there needs to be a way to set the privacy preference at the OS level so apps can look for it.

How it works

Do Not Track can be enabled by accessing the preferences panel from a device running on Boot to Gecko. Just like in Firefox and Firefox for Android, the user scrolls to Do Not Track and turns the setting on (see illustration above). From that point forward, the device broadcasts the “DNT:1″ header. Any Web sites visited by the user and all apps running on the device can see the header, including any third party services running on those sites or apps.

Take for example the case of one leading mobile advertising company, Jumptap, which announced last week that it supports Do Not Track. For Book to Gecko users with DNT enabled either visiting a Web site via their mobile browser or running an app both with ads being supplied by Jumptap, the company shows the user untargeted ads and updates the user in its systems as opted-out. Presumably, this would also be the case for companies like BlueCava that use device fingerprints to identify devices across sites and apps. BlueCava was one of the first to implement support for Do Not Track.

Next steps

Our implementation in Boot to Gecko is intended to demo how the privacy feature can work with apps and encourage others to try similar implementations. As we saw with desktop with IE, Safari and soon Chrome and Opera, we hope other mobile OS providers will join our efforts on Do Not Track for mobile. We plan to begin working with app developers, too, to provide support for the privacy header. We’ll begin by focusing efforts on contributors to Mozilla’s Marketplace, which we announced would open for app submissions soon. We’ll also look to develop best practices with other app platform operators, which recently agreed to a request from California’s Attorney General to do more on privacy.

Through our work with the W3C Tracking Protection Group we’ve also started working on a three-state Do Not Track setting. Today, Do Not Track is either “off” or “on.” This doesn’t satisfy all the use cases on the Web nor fit well with laws in Europe. The three-state setting for Do Not Track will consist of “no preference,” “do not track,” and “allow tracking.” Details for how these preferences will be presented to a user are still being worked out, and we hope these will present some good opportunities to work with other browsers and the advertising industry to finalize the UI for Do Not Track.

I’ll be discussing our thoughts on Do Not Track for mobile and other privacy and security considerations as a speaker on Thursday’s “Mobile and Privacy: Are they Mutually Exclusive” at Mobile World Congress. If you’re in Barcelona, please join us.

Alex Fowler

Mozilla Led Effort for DNT Finds Broad Support

Alex Fowler

8

We’re excited to see the White House and Commerce Department unveil their much-anticipated consumer privacy white paper and call for a Consumer Privacy Bill of Rights today. The team there put a tremendous amount of work into gathering public input and it’s great that they had the idea to evolve standard Fair Information Privacy Practices to be even more about protecting consumers as opposed to rote compliance.

Regarding industry announcements being reported on Do Not Track, here are three cool things we expect to see happen at a White House event today:

  • Google commits to adding Do Not Track to their Chrome browser and respecting it in their advertisements. Welcome, Google!
  • Big advertisers in the DAA industry group commit to responding to the Do Not Track header. What that response will be is still unclear, and we have some ongoing concerns to resolve, but this is a big step forward for industry to make this commitment.
  • The Federal Trade Commission states that they will enforce Do Not Track. While Do Not Track remains voluntary for companies, any company that commits to implementing Do Not Track yet breaks that commitment is subject to FTC action.

As recent press makes all too clear, users’ needs for online privacy are not being fully addressed today, which is why the Federal Trade Commission called for a Do Not Track solution in the first place, and why 18% of mobile and 7% of desktop Firefox users already choose to turn on Do Not Track.

We’re encouraged to see increased momentum for Do Not Track. And as of today, it’s safe to say it’s here to stay.

Mozilla was the first company to include DNT in a browser when we added it to Firefox a year ago this month, and it’s been awesome to see others follow our lead. We want to continue to see Do Not Track evolve through the Internet’s rich tradition of open development and collaborative innovation. Do Not Track is too important to become a product of closed-door meetings rather than through open, multi-stakeholder efforts.

As we continue to work on Do Not Track, Mozilla is firmly committed to user sovereignty and meaningful privacy choices. We hope to be able to design and build a Do Not Track feature that achieves three goals:

  1. Real choices: give users actionable and informed choices by allowing them to opt in or out of data collection and use.
  2. Limited data: collect and retain the least amount of information necessary, and use anonymous, aggregate data whenever possible.
  3. User control: put people in control of their information and online experiences.

These are inspired by Mozilla’s core privacy principles, which guide our data practices and operations.

Mozilla will continue to work at the W3C, which has a vital role to play in creating an international standard for Do Not Track that represents the consensus of a broad group of stakeholders. Mozilla’s Do Not Track Field Guide provides guidance, examples and sample code for anyone interested in implementing Do Not Track and we’ve already worked with several DAA members and other organizations to help them develop and fine-tune their own Do Not Track implementations. Update: Congratulations to DAA member Jumptap for being the first mobile ad network to respect Do Not Track via mobile browsers and apps.

As we’ve demonstrated over the past year, we stand ready to work with the DAA and its members, both within the W3C and through other fora, to make Do Not Track a fully working system. And if Do Not Track fails to materialize as a productive tool, we’ll look to develop other technical measures to ensure that users’ privacy preferences are respected.

Alex Fowler

Mozilla to Offer New User-Centric Services in 2012

Ben Adida

35

At Mozilla, we’ve long focused on building software that gives users sovereignty over their online lives. This means designing in ways that provide people deeper insights into how the web works, unique software features to personalize their online experience, and controls over their personal data. Lately, we’ve been thinking about how user sovereignty has grown to depend on more than just the browser. Many web sites store extensive user data and act on behalf of the user. While the browser may be fully under the user’s control, many of the services that users enjoy are not. Sometimes, these web services handle data in ways that are of questionable value to the user, even detrimental.

It’s clear that Mozilla needs to step up and provide, in addition to the Firefox browser, certain services to enhance users’ control over their online experience and personal data. Mozilla’s Chairwoman, Mitchell Baker, puts it this way:

I believe it is imperative we develop additional offerings. We need open, open-source, interoperable, public-benefit, standards-based platforms for multiple layers of Internet life. [...] We choose to take our values to where people live.

The services we’re imaging and working hard to launch over the coming weeks and months include: an innovative approach to identity, a mobile web-based operating system, and an app store. To offer these services, we’ll need to store user data on Mozilla servers at a much larger scale than we have to date. This requires great care and deliberation. We’ve started the process of figuring out how to do this and tried a few pilot evaluations. I’d like to tell you what we’re thinking and solicit your thoughts and ideas.

Our Current Approach — Firefox Sync

Mozilla already stores encrypted data with Firefox Sync, which lets millions of Firefox users keep bookmarks, history, and passwords synchronized across multiple installations of Firefox, including Mobile Firefox. We secure this data with cryptography more advanced than even that used by financial institutions. Typically, banks use transport-level encryption  (SSL): your data is encrypted in transit between your browser and the bank’s servers. Once it arrives at the bank’s servers, it is, of course,  decrypted. By comparison, Firefox Sync uses application-level encryption: your data is encrypted by Firefox before it’s sent over the network, and it stays encrypted once it arrives on our servers and is stored on our disks. Only your Firefox client can decrypt the data. Mozilla doesn’t have the decryption keys.

This means that we never see your data. If we suffered a server breach, or if someone walked out of our data centers with a few hard drives in hand, then your data would remain safe from prying eyes. Few other companies go to such lengths to secure your data.

The new services we envision will, whenever possible, continue to use this level of data security.

Limits of Application-Level Encryption

If we can’t see your data, then you’re incredibly safe, but we can’t do much to help you either. Application-level encryption is like the safe you keep in your closet: you can place valuables there, and you can retrieve them if you’re there in person, but you can’t easily ask a roommate to quickly tell you over the phone how much cash you have stored in the safe. By comparison, it’s easy to call a roommate and ask them to read you a phone number you left on the kitchen table. Some data is so valuable you need to keep it in a safe. Other data may not be quite as sensitive, and may be quite a bit more useful if you can get help managing, retrieving, and processing it. Something as simple as sending you reminders of friends’ birthdays requires the service to see that data when you’re offline.

I wrote previously about the limitations of encryption to safeguard data. Encryption isn’t magic. It isn’t appropriate for all applications. If we want to provide realistic alternative services that set an example of user sovereignty, then that will require storing user data on our servers, often without application-level encryption.

Design Guidelines

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

We want to vet every feature we consider by relying on existing  processes that the Mozilla Project knows well already: Bugzilla. Issues will be tracked in Bugzilla, with a high-level tracking issue we expect to call “Data Safety.”

People

The following people have joined 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, that’s me, I lead the Identity work at Mozilla

We  know we’ll need to grow this team to include individuals with more diverse backgrounds, people from inside and outside the Mozilla Project, and people from around the world. We’ll also need to be mindful of various local jurisdictions and customs in the way we design and host our services.

Beyond Compliance

Data safety requires careful compliance with regulation and best practices, but we aim to do more. We’ll be involving our most experienced software architects and security experts to  determine how to engineer better privacy. These discussions and iterations, like all existing security  and privacy reviews, will be public by default, so that they can be audited just like our source code (except when  those disclosures would give attackers a head-start, of course, in which case we’ll keep the information secret temporarily.) In addition, like all Mozilla projects, we’ll involve our users in the process of architecting for greater user sovereignty. It’s crucial that users understand the solutions we propose, the benefits provided by these solutions, and the ways in which their data is used to derive this benefit.

Sticking to our Principles

User sovereignty requires a great browser and a number of user-centric services. We would like to build some of these services, and we intend to do so with as strong a dedication as ever to our privacy principles: no surprises, real choices, sensible settings, limited data, and user control. We won’t sell or give away your data. We will always explain what data we store and why we store it. We will always let you leave and take your data with you, and we will always explain what benefit you get from this data collection.

We welcome your feedback, in blogs, on dev.planning, or on Twitter with the hashtag #mozdatasafety.