Monday, December 19, 2011

seat belts and airbags

As much as I like giving users choice and control, bombarding people with too many options makes using software painful.  This is why it is important to consider both defaults and flexibility of all the privacy-impacting features we roll out -- the airbags and seat belts of the software industry.  Not everyone who cares about privacy know how to configure Firefox (or any software) to precisely suit their needs.  Those who are both care about their privacy and know how to configure software to precisely what they want are not the same; those with both qualities are often Privacy Professionals, or they work in a related field.


A couple of weeks ago, I was inspired by some stuff Dr. John Guelke  said to segment my thinking on privacy into two efforts: the privacy feature seat belts and airbags.  He approaches privacy as something driven by social norms, whereas until recently, I mostly thought about it as a subjective choice about what I want with my identity and data.  In fact, both of these perspectives are important, and they must work together to create the most positive effect for the Web.  There are distinctly different reasons to provide certain safe defaults than there are to provide features users ultimate control: the airbags can help protect everyone†, and the seat belts†† will protect those who know to use them.

Choice and Control (Seat Belts).

It's crucial that people have all they need to maintain complete control over their experiences online, or the web becomes controlled solely by the businesses on it and not the people who live in it.  Increasingly, people are performing more of their everyday activities online and deserve to be as much a part of their activities as they would in the real world and this is why I care so much about giving people who want it control over each bit of how they see and interact with the web.  This is the reason Do Not Track was built into Firefox, and this is why software allows people change how the browser handles cookies. These features empower users to control their experiences online.

Users enable and deploy these features on their own.  Firefox doesn't turn on Do Not Track by default, because it's a seat belt.  People choose if they want it or not.

Social Norms (Airbags).

There are expectations about what people understand that are consistently held by a society or group.  These social norms dictate expected behavior and, though not something that limit behavior, can be seen as social defaults.  These norms change and fluctuate with the society, but you could say they are precisely what any member of the society expect to happen.

The Web is a society of sorts, and people carry over their social norms from physical interactions with people to those interactions with web sites and corporate entities online.  Here is where the social norms very importantly dictate the defaults of how a web browser should work (and frankly, how web sites should work too).  People expect a site to remember small bits of information about their interactions, such as what is in their shopping cart, and this is why cookies are enabled by default, like an airbag.  People do not expect to disclose their precise location to web sites, and that is why Geolocation is not activated by default.



Directing Efforts.


There are two driving forces here that dictate the best paths forward for inventing and building privacy features into the web: social norms, and individual choice.   It's easier to listen to the cry or predict a need for individual choice; we can create any feature as if it were a seat belt -- features that users may or may not want to enable.  The harder direction is understanding and following social norms, or what people expect without request or action.  These are hard because they differ not only with time, but also across different groups of people.  Technologists like me can more easily understand our subculture's values and build those into our software.  We have to be careful, though, since society as a whole may not have the same values as our smaller group of software developers.  We as an industry need to focus on what benefits all as a sensible default, and that may be completely opposite of what we computer geeks think.

We need a better understanding of social norms and how they relate to people's data online.  That understanding can help map norms to the defaults we build into all the web-oriented software we make.  Everything else then should then be an optional feature, like a seat belt.

Though you may not use all of Firefox's privacy features, I do recommend wearing your seat belt.  Really.  It could save your life.  :)


--- Footnotes:---

† = Okay, so the analogy breaks down since airbags aren't good for you unless your seat belt is engaged, but the gist is that you don't have to think about the airbags.

†† = And sure, "everyone" knows about seat belts, but pretend for this argument that they don't and the feature is more like those glass-breaking hammers that you can buy to free you from a submerged car; you can buy and use them, but they don't usually come with your car.

Wednesday, November 09, 2011

Firefox won't activate DNT by default

Firefox isn't gonna turn on DNT by default because then DNT won't work.
"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. "

(Link)
Sure, we could run a few engagement campaigns to inform people about the option, but we won't make that decision for our users.

Edit (9-Nov-2011 @ 11:24): 

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

We're defaulting to state 3: we don't know what the user wants, so we're not sending any signals to servers.  The signal being sent should be the user's choice, not ours, so we don't broadcast anything until they've chosen what to send.

Wednesday, September 28, 2011

Measuring Progress

In the reasonably short time that I've been involved with Mozilla, we've made amazing changes to the web and our Firefox browser. We've seen the adoption of HTML5, open video, and a slew of other features. This means the web is yet even more complex and by extension, so is Firefox.

Sometimes Firefox doesn't perform as well as it should, and it's hard for us to understand why.

Enter the Telemetry project. Our performance team, led by Taras Glek, developed a feature that lets us measure performance-related stuff as you use Firefox. Starting with the version of Firefox released today, you have the opportunity to opt-in to send us some of these statistics. They're not tied to you, and we will take a look at the data in aggregate to see if there are widespread problems in the various bits of Firefox's plumbing.

I posted a note about this over on The Mozilla Privacy Blog. As we deployed this feature, we worked hard to make sure that our users will have choice and control of the data they send us. This involves a few bits of critical thinking: first, we have to make sure you're not surprised about this.  Second, we make sure that we're only collecting what we need to make Firefox better. Third, our practices must be transparent (and not just open source, like we try to be clear about what we collect).  Fourth, we make sure that you know you're sending us this data and can make it stop if you want.

We wrote down how telemetry works for you to read (if you want) and how the feature lines up with our promises put forth in the Privacy Operating Principles that we've been working with for a while now. As we add new probes to telemetry to see where to improve Firefox, we'll be cataloging those as well, including risk analysis for stuff that's remotely private.  We'll never collect stuff like your address or credit card numbers through this system (that'd be weird), but we may want to know which of the add-ons you're using that are slowing down Firefox.

This risk analysis and privacy review are the things we plan to do with new Firefox features that involve your data; whether or not we collect anything, it's important that we live up to the operating principles we've put out, and Telemetry is an early example of how we plan to keep you in control.

Thursday, September 22, 2011

Careful... pixel-data access is pointy

Robert O'Callahan writes:
Some Web applications require the pixel data of Web pages to be exposed to Web applications [...] There are some pretty big security implications here. The biggest problem is cross-origin information leakage.
He's right on. This has a bunch of subtle risks to haphazardly implementing pixel-data access. The one near and dear to my heart is the risk of defeating what we shipped a while back to stop the CSS- and JavaScript-based history sniffing. Draw links, read colors, defeat fix. Not good. We can't just lie to the content script attempting to access the rendered data -- once it's drawn, it's really hard to figure out what's a link and what isn't. So what do we do? Take a look at this and the other issues with implementing pixel-data access over on his blog. If you've got ideas, we're all ears.

Thursday, September 08, 2011

mozilla privacy blog

Hey, good news! Mozilla has a privacy blog where we will be blogging about all sorts of privacy stuff.

I'll continue to write about it here, but check it out for more reading. The latest post by Alex Fowler announces a field guide to DNT that discusses what to do when you receive the header, and what some other sites are already doing. He also talks about how many people have turned on DNT.

Check it out: Mozilla Privacy Blog

Thursday, July 14, 2011

on unifying site behavior and consent

Lets face it, the users of your ShinyNewWebSite(beta) will never know exactly how it works. Perhaps that's by design (look, it's magic!), perhaps that's simply because they're not computer programmers, but this is the reality.

So there's this problem: how do I get users to provide informed consent to use my shiny new data collection web site? I want to do some really cool stuff, but I want the users of the site to know what's happening and feel in control.

This is hard. I think there's a ton of value in data mining and personalization, and it's not reasonable to expect users to comprehend the entire process of how their data is collected and used. We do however need to empower users to manage trust for the organizations who collect and use their data, and one way to do this is to get them closer to understanding what happens.

Here's one way I've been thinking about this: on one end of a spectrum are the users; they have values and want to assert protection over some of their data. On the other end of the spectrum are the web sites; they produce value from the users' data and want to be honest and compliant with users' desires. Right now there's often a huge gap between what users want and what sites actually do with their data. We need to shrink this gap.


I've talked about this gap from a user's perspective before (the privacy perception gap) and ultimately this gap leads to shock and discomfort. In Firefox 4, we deployed DNT as one feature to help shrink the gap from the user's informed-consent side.


Anything we can do to help make obvious users' preferences and privacy choices shrinks the gap from the user side, but we should work from the site's side as well, and hope the efforts meet somewhere in the middle. What else can we do to help bring site behavior into to the user's mental model of what's going on?


We need something new to improve upon privacy policies. We need something more objective than self-explanation. We need something empirical that can be measured, digested and shown to users. We need technology that makes it easier for people to peer into the opaque bits of the web and see what data is collected and how it's used. While it's not realistic to expect a silver bullet that makes all users instantly understand how sites work, we should still try hard; let's throw all the ideas that we have out on the table and approach this gap with as many tools as we have to try and shrink it.

Monday, June 20, 2011

Markus Jakobsson: why we must ask "why" in designing secure systems

On Wednesday (June 22 @ 12pm PDT), Markus Jakobsson will talk about some of the security research he's been working on. Join us to hear some stories and learn how and why to build in security from the ground up! Details below. This will be streamed to the world on air mozilla, and hosted at the Mozilla HQ in Mountain View.

22-June-2010 EDIT: The video is available here.

Where:Mozilla HQ (10-forward) and Air Mozilla (marketing site)
Speaker:Dr. Markus Jakobsson
Subject: "Why we must ask 'why' in designing secure systems"

Summary: Computer security has a tradition of responding to the symptoms of problems without taking the time to ask what the sources of the problems are. Markus will argue that this approach has made the user authentication experience frustrating and vulnerable; enabled phishing; and created a tremendous market for malware. Markus will give examples of some well-known approaches that were designed without a thorough understanding of the underlying problems and limitations, and how they could be redesigned and improved. In particular, he will cover web and app spoofing; mobile passwords; and bullet-proof detection of malware.

Join Us!

Thursday, May 26, 2011

managing your relationship with sites

This post is co-written by Margaret Lebovic and Sid Stamm. This article is cross-posted on Margaret's blog

As the web becomes more and more complex (and AWESOME), it's important that you can manage your relationship with the variety of sites out there. Sure, Firefox 4 has a Page Info dialog that lets you control what a web page is allowed to do, including whether you want to let it store data on your computer, access your location information, open pop-up windows, and on and on. However, this dialog only lets you manage your relationship with the one page you're currently visiting, not the entire set of sites you visit on the web.

We think it's important to be able to manage your whole relationship with web sites in an intuitive way, and that's why we're exited to show you what we've started working on: a site-based permissions interface.


This feature is still experimental, but you can give it a shot. In the future, we'll be putting some polish on the UI, adding more controls like "always access securely" (HSTS), and hopefully giving you a better view of what a site knows about you. We also want to integrate this permissions manager with the site identity block in the location bar for quick and easy access.

Try it out! Grab a Firefox nightly build and try out the feature by typing about:permissions into the location bar.

(Credit: thanks to Jennifer Boriss, Medhi Mulani and Margaret for all the hard work on this project.)

Friday, May 20, 2011

Do Not Track -- Now on Firefox Mobile!

Since we first announced our implementation of the Do Not Track HTTP
header
, we've seen an amazing amount of support from trade groups, and even other browser makers.
To build on our view that you should have control of how you're tracked
on not only desktop computers but also your mobile devices, we're
excited to announce that the latest beta of Firefox for Android also includes this feature.

You can enable Do Not Track in the latest beta of Firefox for Android through an
easy-to-find switch in the preferences--see image to the right, and websites will see exactly the same signal that Do Not Track-enabled desktop browsers send. Every time Firefox loads a web page, image, or advertisement it includes a "DNT: 1" signal that tells the entire web you don't want to be tracked.

The web on your phone should be the same web as on your desktop, so to
provide this consistency we've put the exact same Do Not Track feature
in both the desktop and mobile versions of Firefox.

Try it out today! Grab the latest beta of Firefox for Android and turn on the feature. If you visit my blog from Firefox (mobile or desktop) with Do Not Track turned on, the widget below will glow green just for you.

Sunday, May 15, 2011

Clearing Flash cookies using Firefox

Back in March, we shipped Firefox 4 with a feature that sends a signal to plugins like Flash and Silverlight when you clear your cookies. Adobe has announced that starting with Flash Player version 10.3, they'll be listening to the signal! This is exciting, because clearing your flash cookies is as easy as clearing regular cookies in this latest version of flash.

Here's when Firefox 4 tells Flash Player version 10.3 to delete LSOs (Flash cookies):
  • When you clear all your cookies in Firefox using "clear recent history" [how-to link]
  • When you choose "forget about this site" in your library (history) window [how-to link]
  • When you quit Firefox, if you have Firefox configured to clear your cookies automatically upon exit [how-to link]

Chrome and Internet Explorer are also supporting this behavior, so this is fantastic news for everyone's privacy on the web!

More reading for techies:

Thursday, March 24, 2011

Force-TLS compatible with Firefox 4!

I've updated the Force-TLS Firefox Add-On to work with the newest version of Firefox! Force-TLS version 3.0.0 should work in all Firefox 3.0 and newer.

So what does this mean? Well, HTTP Strict-Transport-Security (HSTS) is implemented in Firefox 4, and that's a pretty similar technology to Force-TLS. In fact, it is nearly identical except there's no UI in Firefox 4. If you install Force-TLS, you'll get a UI and also get the built-in HSTS support that's implemented much more completely and efficiently than any add-on. A while ago, I blogged about an experimental add-on called STS-UI that adds a UI to HSTS; Force-TLS shows essentially the same user interface but I've been wanting to keep both the back-end for Firefox 3.x and the front-end for all versions of Firefox in the same add-on.

So what's new in version 3.0.0?
  • Smarter: The invisible bits of Force-TLS are restructured to use the custom HTTPS-upgrading and header-noticing bits for earlier Firefox versions but use the HSTS back-end built into Firefox 4 when it's available.
  • Better: A few bugs in the user interface were fixed.
  • Organized: I've moved the code into an open source repository.

I've got a list of enhancements queued up for the next version of Force-TLS, but not a whole lot of time to work on it. If you'd like to help make Force-TLS more awesome, send an email to forcetls@sidstamm.com

Previously:

Wednesday, March 09, 2011

Do-Not-Track Standardization has Begun

Thanks to a lot of hard work by Jonathan Mayer and Arvind Narayanan (the donottrack.us guys at Stanford), we've submitted a draft specification to the IETF for review. We've proposed a specification that not only outlines what the DNT HTTP header should look like, but also how servers can honor a user's choice for privacy.

This draft is just the beginning: there will be much debate, but we want you to be part of it.

More:

Monday, February 07, 2011

Get your DNT header for older versions of Firefox!

When we recently announced our intent to add a do not track header to Firefox, we focused on how it will probably be available in a future version -- Firefox 4.0. But what about people who would prefer to use previous versions of Firefox? How can you get the HTTP header into version 3.6, or even earlier versions?

Though we recommend using our latest and greatest product, there's an add-on you can install to add the "DNT: 1" header to older versions: Universal Behavioral Advertising Opt-Out (a.k.a. UBAO). The name is a mouthful, but its operation is simple: installing this add-on is like ticking the checkbox in new versions of Firefox to send a "DNT: 1" HTTP header with all requests your browser sends out.

There are other add-ons that send the header! AdBlock Plus and NoScript send the header too, but if you don't want the extra features that come along with those add-ons, UBAO is for you.

Monday, January 31, 2011

Try out the "Do Not Track" HTTP header

Last week, I blogged about some of the work we're doing at Mozilla to help people better control how they're tracked as they browse the web. The basic idea was to give people a universal "opt out" of tracking for behavioral advertising. A Firefox user will be able to check a box in the preferences dialog and then a HTTP header would be sent with all HTTP requests so all servers know the user wants to opt out.

Well, I'm excited to report that we've landed the first iteration of this feature into Firefox nightly builds (the pre-beta builds that are rough around the edges)! If you'd like to try out the feature, grab a nightly build; I must warn you though, these nightlies are not as stable as the beta releases.

In the build, to enable the feature, open the preferences pane and select the advanced tab. Tick the box that says "Tell sites I do not want to be tracked" and start browsing.




Every connection your browser makes to download content will send a signal that says "don't track me." Literally, it looks like this to servers:
DNT: 1
Note: this is different from the initial experiment that used "X-Do-Not-Track" and my original post last week that said "Tracking-Preference: do-not-track"; it's both shorter and very precise. The researchers at donottrack.us are also recommending this syntax.

I encourage you to try out the test builds, or if you'd like to wait for a more stable version, wait for an upcoming beta release with the feature in it. We do not anticipate that sites are looking for the signal yet, so you probably won't notice a difference as you browse the web. I'm hoping to have a demo site available shortly that will give you an example of what types of changes you might see using this feature -- and when I do, I'll post a link here.

Sunday, January 23, 2011

opting-out of behavioral ads

One of many planned explorations towards a more elegant and privacy-enhancing approach to user choice and control.

I've recently been blogging about online tracking and behavioral advertising, and I think it's time to take the first step towards a solution. Complete solutions to the transparency gap and lack of user-data control are being actively explored and as part of Mozilla's larger aim to improve users' control over their data, we want to take the first step. I'm proposing we implement a HTTP header that Firefox users can elect to send that tells ad networks they don't want to be tracked.

What is tracking in the context of "Do Not Track" for Online Behavioral Ads?

The definition here is hotly debated, but the general consensus seems to include at a minimum:
Tracking is the accumulation and use of a profile by advertising networks through invisible or subtle noting of which sites an individual visits, and the use of the profile data to customize advertisements displayed.

Currently, to opt-out of online behavioral advertisements, you have to get a site to set an "opt-out" cookie so they won't track you. There are various web sites that help out (NAI, IAB UK) and there are Firefox Add-Ons (TACO, beef taco, etc.) that can streamline this process. But this is a bit of a hack: it's nearly impossible to maintain a list of all the sites whose tracking people may want to opt-out from. It would be more attractive if there was one universal "opt-out" signal that would tell all sites you want to opt out.

Bug 628197 calls for the implementation of a HTTP header that is transmitted with every HTTP request that advertises the Firefox user's desire to not be tracked by advertising networks. A checkbox in Firefox's preferences panel could ask if the user wants Firefox to request opt-out from tracking, and when checked the HTTP header "Tracking-Preference: do-not-track" will be sent. This is a similar approach to others that have explored an HTTP header for opt-out (donottrack.us, UBAO), and I agree it's a good step to take.

Servers don't know about this yet, so it won't have immediate effect on tracking, but in the meantime the presence of the header can be observed by web sites (in a similar way to a cookie) to help understand how desired opt-out of OBA is. Once this feature ships in Firefox, it's time for web sites to do the right thing; honor users' choice when they receive Do Not Track HTTP headers and opt-out these users from tracking.

Mike Hanson has also been thinking about this for a while. He's written a good analysis of problems surrounding online tracking, including a survey of some approaches we could take. An HTTP header that expresses a user's desire to opt-out seems to be the most productive step we can take that doesn't shut off important and innovative bits of the web that fund many of the services and content we make use of in our daily lives.

Do Not Track HTTP headers for behavioral advertising are only one piece of the data choice and control puzzle.

Improving transparency into online data collection and sharing practices is another step that we think will help set peoples' minds at ease. Additionally, we're still working on other technology at Mozilla to improve people's control over how they're tracked online -- features that aim to give people a deeper understanding of how tracking happens, and the ability to shut it down when the Do Not Track request isn't honored. In concert, I hope the HTTP header and future efforts will help people regain transparency and control over how they're profiled or tracked online.

EDIT: Test builds of Firefox are available here if you want to try out my initially proposed implementation. Of course it will change before we ship, but these builds provide a proof of concept.

EDIT: The newest Firefox 4.0 beta has the initial implementation in it. Download the beta if you'd like to try it out!

Tuesday, January 18, 2011

privacy operating principles

I'm very excited that Alex Fowler has joined us to help tackle the data sharing (a.k.a., privacy) problems of the web. I look forward to working with him to make the web a safer place. Welcome, Alex!

His inaugural post on the new "First Person Cookie" blog describes the operating guidelines we've been trying on for size. Take a read and let us know what you think!

Tuesday, January 11, 2011

write your name on this list, and I won't identify you

Let's discuss the idea of a do-not-track (DNT) list developed like a do-not-call (DNC, not to be confused with a political party) registry. The DNC registry is a list of phone numbers that telemarketers are forbidden from soliciting. The list is published so telemarketers can self-police (or more bluntly, avoid fines). What if we implemented a do-not-track list in the same way? We'd have to be able to identify every person accurately from within the browser, and compare them to a public list of identities; every web site must be able to identify you to comply. This sounds kind of scary to me. An opt-out-by-list scheme that requires identification of everyone who doesn't want to be tracked.

To be fair, there's a major difference: DNC is about preventing annoyance, DNT is about preserving privacy. But both are opt-out lists.

So lets take a step back and look at the bigger picture. It seems to me that there's a bit of a conflict in opt-out for privacy: somehow, you have to be able to identify the folks who are opt-out-electees. This inherently reduces the subjects' anonymity by either maintaining a list of those who wish to remain anonymous, or tagging people who want to be anonymous with an "I opted out" sign. So you have a choice: keep a list of identities of those who want to be anonymous, or make them self-identify by, say, wearing a big red A on their shirt. (A for "Anonymous" of course.) I guess this makes me lean towards opt-in for things that reduce anonymity since people who agreed to concessions in privacy will be less likely to resist tagging and list-membership.