Mozilla to Offer New User-Centric Services in 2012

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.