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: only disclose information with a user’s consent. 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.

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

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.

DNT is often compared to other browser security and privacy features, such as malware and phishing protection. This reveals a common misunderstanding about what sort of feature DNT is and what it does. That’s why we think we should shed a little more light on Firefox’s DNT defaults.

DNT is different. It doesn’t take away a broken feature, or fix a bug. It adds a new feature that’s incredibly important: the user’s voice. We ship DNT by default: the feature is there, and you can use it if you want. When DNT is off, it doesn’t mean “please track me”, it means that the user hasn’t told the browser their choice yet.

• DNT:0 means “I consent to being tracked”.
• DNT:1 means “I object to being tracked”.
• If the signal is not sent, we are not communicating either of these things.

We ship Firefox with DNT in the “don’t tell sites anything” configuration because initially, that’s all we know. Until the user tells us what to send, we don’t want to put words into their mouth. Neither Mozilla nor Firefox controls what sort of privacy protection sites give their users. Those decisions are up to sites and to regulators.

DNT allows for a conversation between the person sitting behind the keyboard and they site that they want to visit. If DNT is on by default, then 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. Right now, DNT is best explained as a vote for privacy, not a magic “keep me safe” button.

As Do Not Track picks up steam and standardization is well underway in the W3C, people have begun asking, “If Do Not Track is so good for the web, why don’t you turn it on by default?”

Frankly, it becomes meaningless if we enable it by default for all our users. Do Not Track 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 Firefox being tracked, it’s the user.

Mozilla’s mission is to give users this choice and control over their browsing experience. We won’t turn on Do Not Track by default because then it would be Mozilla making the choice, not the individual. Since this is a choice for the user to make, we cannot send the signal automatically but will empower them with the tools they need to do it.

Do Not Track is not Mozilla’s position on tracking, it’s the individual’s — and that’s what makes it great! For that reason we have no plans to turn on Do Not Track by default.

Sid Stamm
Lead Privacy Engineer

In looking at adoption of the Firefox Do Not Track (DNT) setting over the past two months, more than three times as many of our users have turned on DNT in Firefox Mobile than on desktop versions of Firefox.* The percentage is just over 17% on Firefox Mobile, compared with 5.6% on Firefox.

We don’t know the exact reason behind the higher adoption rate for DNT of our users in Firefox Mobile. It may be that people seeking alternative browsers to the default ones on Android devices are more technically savvy and likely to tweak settings than other users. Or it may reflect that the settings UI is stripped down with all the settings appearing on one pane, versus multiple tabs within the desktop preferences window. It could also be that people have increased concerns over privacy and tracking on mobile devices.

By way of background, Firefox Mobile is the only mobile browser that includes DNT today. We implemented the same Do Not Track privacy setting in Firefox Mobile for Android that became available to our desktop users at the beginning of the year. Firefox Mobile users enable the DNT setting in the settings pane and flipping on the “tell sites not to track me” switch. Once on, the mobile browser sends an HTTP header that reads DNT:1 to all first and third parties involved in any particular session.

With users increasingly browsing the web on mobile devices, we need to ensure that any DNT system works in browsers on both desktop and mobile devices, as well as on mobile apps used to access content, services and games on the Internet. It’s important to point out that DNT on a mobile browser doesn’t control how other apps installed on a device operate. This is an area where DNT still needs much more thought, otherwise we create a privacy system that is incomplete and doesn’t fully reflect the ways in which we access the Internet today. I’m also concerned about app-level DNT settings, should they emerge, where users end up having to enable and re-enable DNT from app to app. Perhaps DNT should be an OS-level setting. More work within the mobile industry is definitely required here.

Alex Fowler

*We don’t track users to determine these percentages. These stats reflect aggregate counts that we generate from recording the daily numbers of HTTP headers we receive that include DNT. Any well trafficked site can record these stats, including being able to also count the number of users with DNT enabled via Safari and IE9.

Mozilla introduced the Do Not Track privacy feature to give users a way to tell companies they don’t want to be tracked online. We’ve seen growth and adoption of Do Not Track and are pleased to note that today, AdTruth, an Associate Member of the Internet Advertising Bureau (IAB), is launching patented device identification technology that honors the Do Not Track header that Mozilla introduced earlier this year. When people enable the Do Not Track feature in their browser, AdTruth’s technology will opt them out of tracking.

Check out the AdTruth announcement for more information.

Sid Stamm
Lead Privacy Engineer

Last week saw the first meeting of the W3C’s Tracking Protection Working Group, a cross-section of advertisers, browser vendors, publishers and public interest groups come together to agree on a standard for Do Not Track (DNT).

We believe the group’s mission is vitally important. Without a well-defined DNT mechanism, it has been common for Web users to have their reading habits recorded by companies they have never heard of, and have no relationship with. Sophisticated tracking techniques have been appearing faster than users’ ability to defend against them. The mission of this working group is to give readers a simple and meaningful way to regain control.

Last week’s Working Group turnout was comprehensive, with about 40 folks present from a variety of organizations — comfortably more than the ten required by the charter. The chairs, Aleecia McDonald (Mozilla) and Matthias Schunter (IBM), emphasized the need to work quickly in producing this consensus standard and outlined an aggressive schedule, with the next meeting at the end of October, and a Last Call Working Draft expected before the end of the year.

In two days, we made healthy progress, agreeing broadly on the DNT header in its current form, and brainstorming ways to extend it into a more refined standard. There was no shortage of ideas around the table and we put together quite a to-do list of topics to work on in the coming weeks and months. Although there was healthy discussion on most of the issues raised, there was a surprising amount of agreement on many of the substantive questions, which bodes well for the production of a robust and widely-used standard.

The entire workings of the group are public. If you’re interested, then you can sign up for the group’s mailing list, which is also publicly archived. The minutes from both days of last week’s meeting are available, and further updates, including minutes of the weekly conference calls will continue to be archived on the group’s page.

This post was co-written by Peter Eckersley of the EFF, and Tom Lowenthal from Mozilla.

For a while now we at Mozilla have been talking about our privacy operating principles. We’ve been working hard behind the scenes to make sure we deliver on these promises, and want to share a little bit of the backstage work we’ve done to make Firefox live up to these promises.

In the latest version of Firefox, you’ll be given a chance to enable a new feature called Telemetry. This feature measures different bits about how Firefox is performing for you and sends these usage statistics to us so we can figure out where to focus our efforts to make it even better. Here’s how it lines up with our principles:

No Surprises: we ask before enabling Telemetry, and you can turn it off whenever you want in the Firefox options dialog. We’re not gonna collect any of this stuff until you say it’s okay.

Real Choices: When you update or install Firefox, it will ask if you want to help us out, and tells you about the kinds of data we will collect. Additionally, we’ve worked through many of the privacy implications of collecting this data — and that took a little work. We wrote it down for you to see why we’re collecting the data and the risks we’ve considered in our Privacy Review wiki pages for the Telemetry feature and each thing we want to measure. You can also download the about:telemetry add-on to see everything we’re collecting from you.

Sensible Settings: the data is sent to us over a secure (HTTPS) connection to our server, and is off until users enable it.

User Control: as the data collected is not personal information and it is stored in aggregate form, we won’t be publishing any data specific to you. Our performance team will probably talk about the aggregate statistics of the whole Firefox population (averages, trends and such), but we delete the anonymous data you send us when we can no longer use it to help us make Firefox better.

It is really important for us to learn how Firefox performs for you; we have a whole lot of automated tests, but those can only guess how it will work when you’re behind the wheel. So go update or install Firefox, then say “yes” to sending us performance data! You’ll be helping us make Firefox even better in a way that puts you in control of your data, and that’s important because this is your Firefox and we want you to be in charge.

Sid Stamm
Lead Privacy Engineer

As many people know, Mozilla jumped into Do Not Track (DNT) in a big way earlier this year by providing Firefox users on desktop and mobile with a simple way to tell companies to stop tracking them online. We did this before knowing exactly how sites and advertisers would respond. We believed we had to do something to advance the debate and we counted on developers seeing the technical advantages to our approach over current proposals and practices.

Over the past six months, we’ve worked closely with developers at leading advertising, publishing and technology companies to implement DNT. Today we’re publishing our first edition of the The Do Not Track Field Guide.

Based on interactions with developers from leading companies that support DNT today, The Do Not Track Field Guide contains case studies, tutorials and sample code. We’ve also included a background section on our view of what the debate over DNT is all about. We hope that the Guide inspires  developers around the world to embrace the technology and also leads to subsequent editions with new tutorials and sample code.

Why developers care about DNT:

• Browser Support: Mozilla, Microsoft and Apple include DNT in their browsers.
• User Adoption: Millions of people are sending the DNT:1 signal today.
• Better Opt-out: Persistent user preference that can be used to support most opt-out use cases.
• Easy to Implement: Sites with existing opt-outs are reporting straightforward integration of the DNT header into their systems.

With the exceptions of Google Chrome and Opera, all the other major web and mobile browsers support DNT. We’ve had DNT in full production releases of Firefox and Firefox on Android since version 4. Microsoft’s IE9 includes the DNT header with its Tracking Protection List feature. Apple’s Safari added support for the DNT header in the release of Lion this summer.

Our Metrics team has been following adoption (in a privacy friendly way) over the past few months and we’re seeing almost 5% of our user base with DNT enabled (see today’s companion post from the Metrics team on the details). It’s been fascinating to watch the almost .01% increase each day. Another study published a few weeks ago looked at 100 million Firefox users and reported a slightly higher adoption rate of more than 6%. We’ve heard from publishers that they are seeing 1-3% higher rates than ours. If you have a web site, then you, too, can see how many people are asking you not to track them!

One of the most important things we learned in writing The Do Not Track Field Guide is that the companies that offer opt-outs for various tracking and profiling activities today have an easier time implementing changes to look for and respond to a user’s DNT signal. For instance, we spoke with an engineer who implemented DNT at an advertising company. He came to work one morning, read about DNT in Slashdot, wrote a few lines of code and was done before lunch. The advertising company already had an existing code base to support opt-out cookies so he was able to reuse existing code.

Another key learning is that not all opt-outs are created equal. We heard from developers who are excited to support the DNT header because it may someday soon enable them to remove ineffective cookie-based privacy opt-outs that did little to engender trust and sustain a user’s choice across their many desktop and device browsers. Not only is putting the control in the hands of the user better for the user, but it’s also better for the sites and apps from a technical and compliance perspective.

Here’s the PDF version of The Do Not Track Field Guide or you can click on the cover image above. Also, the sample code from the tutorials is available as a Zip file. Finally, you can find the Guide on the Mozilla Developer Network here, where we hope developers will begin to contribute additional implementations for the community.

Alex Fowler

Acknowledgments: This Guide is the result of substantial contributions from Aleecia M. McDonald, Sid Stamm, and our graphic designer Ty Flanagan. We’re grateful to the engineers who shared their implementations with us, as well as the many colleagues who provided us with input on the various drafts.

Update: I removed the statement that more people have DNT on than are using Adblock Plus. We took another look at the numbers and were concerned that we’d compared apples to oranges.

The DNT meme has crossed the Atlantic! Two important policy makers in Europe made statements just one week apart supporting Do Not Track (DNT).  It appears there’s genuine interest by these EU regulators to determine how a website’s support for DNT meets compliance with legal obligations under the ePrivacy Directive.

I was in Paris today where Ed Vaizey, UK Minister of the Department for Culture, Media and Sport, told participants at the OECD High Level Meeting on The Internet Economy that “support for DNT is already being explored in the UK” and is part of the discussions underway by his Department’s Browser Working Group.

The strongest call for DNT in Europe came last week from Neelie Kroes, the Vice President of the European Commission responsible for the Digital Agenda for Europe. She told those of us participating in the Online Tracking Protection and Browsers Workshop in Brussels that “we should collectively pay more attention to the emerging ‘do-not-track’ technologies,” and she challenged industry in Europe to make it happen by June 2012. Here’s the key excerpt from her speech (and make sure you read the last sentence below):

DNT is simple: users can instruct their device or application to accompany all network requests with an indication that they do not want to be tracked. Service providers need to react to such explicit requests.

DNT has a lot of potential because it can apply:

• First, to all networked devices and applications
• Second, to all types of tracking and
• Third, to all purposes of tracking.

DNT is already deployed in some web browsers. And some web businesses say they honour it.

But this is not enough. Citizens need to be sure what exactly companies commit to if they say they honour DNT. For example, there is an important difference between a commitment not to record tracks and a commitment not to use them for a specific purpose once recorded. When this is solved more users will deploy DNT – and it will become simpler – and companies will go along. So we are looking at a virtuous circle.

How do we get there? We need a standard! We need to standardise how the DNT signal and the expected reaction should look. The standard must be rich enough for users to know exactly what compliant companies do with their information and for me to be able to say to industry: if you implement this, then I can assume you comply with your legal obligations under the ePrivacy Directive.

I blogged a few weeks ago how I believe the DNT header can fit with the ePrivacy Directive, but I’ll be very interested to see how the thinking evolves among more knowledgeable policy makers and legal experts. And I’ll be sure to update my blog as I learn more…

Alex Fowler
[Reposted]