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.

Wednesday, December 29, 2010

Do we Understand OBA and Tracking?

With all the discussion in the social and political spheres about online behavioral advertisements (OBA), there's an awful lot of heat underneath the two points of view about tracking.  On one side, people are firmly asserting that most folks don't want targeted ads, while on the other side the assertion is that targeted ads are much much better (and less annoying) and people actually prefer them.

I think there's a bit of a gap in which assumptions are employed.  It's not clear how much the average consumer knows about targeted ads, and without knowing that, we can't assume anything about what they want. Furthermore, if we ask questions that assume unknowns, the results are useless -- asking for approval of targeted ads means two different things if the respondent does or does not understand that the ad network has to profile them to accomplish this.

Collecting Data.
First of all, it's important to acknowledge that these ad networks are already accumulating a whole lot of information for a variety of purposes: click-through rates, ad placement effectiveness, ROI, etc.  They just don't directly tell consumers about this.  In fact, many networks have been tracking individuals from ad impression all the way through purchase (conversion tracking) as yet another metric of successful advertising -- and for those of you who buy ads, you understand how powerful this knowledge is.  These already existing uses of data are incredibly helpful for advertisers (and the networks too, for ad placement), but it's not clear if consumers realize this is happening.

Online behavioral advertising is probably just a new use for already collected data.  The data's already warehoused, and it would take an awful lot of arm-twisting to reduce what ad networks collect -- because it's used for more than just OBA.

So I think the set of questions we ask consumers should be changed from "do you want targeted ads?" to the more precise pair of queries: "is it acceptable for ad networks to build a profile on you?" and "may ad networks use this profile to customize ads you see?"  We don't yet understand if people want this data collected, moreover want it used for OBA.  This distinction is necessary, because I think there are three groups of people here:
  1. people who don't want a profile built or their browsing habits recorded at all.
  2. people who accept conversion tracking but want to see the same ads as everyone else.
  3. people who accept tracking and want the profile created to be used for displaying targeted ads.
My hunch is that group 2 is smaller than 1 and 3, but I haven't seen a survey measure precisely this.

Measuring Desire.
Gallup has taken a step to gather preliminary information about consumer preference; unfortunately, it only seems to address the vague question "is it okay if ad networks show you custom ads?"  I'd really like to see a series of questions that measure habit-tracking approval as well as approval for use of tracking in OBA.  Once we know this, we can figure out if people need a tool to opt-out of data collection, or if a tool to control data use is enough.

My personal point of view (not that of my employer or anyone else) is that OBA is not an invasion of privacy -- the stealth collection of data about my preferences is the invasion.  Perhaps it's worth the convenience like cell phones or ez-pass toll devices, or perhaps it's not.  Whether or not this invasion of privacy is acceptable should be ultimately up to you.  As with many things, you can trade bits of privacy for something new.  Would you like to "buy" better ads with your browsing history?

Monday, December 27, 2010

privacy icons - alpha

Aza posted a fantastic discussion of his privacy icons project, including a whole lot of detail about their purpose and use.

I think these little graphics are going to be incredibly helpful for people who are getting more and more excited about how their private data is being used on the global Internet.  Now, these aren't a perfect solution to make data sharing practices transparent, but it can be a powerful tool for those entities who want to be honest and need a way to tell people what they're doing in a concise, recognizable way that doesn't require them to have a law degree.

Link to http://azarask.in/blog/privacy-icons/

Friday, November 12, 2010

bah. blacksheep.

It's a deeply satisfying way to defeat an attacker: give him a taste of his own medicine, and the BlackSheep add-on attempts to do just that. This add-on listens for Firesheep's patterns on the network and warns a user that they are being watched. BlackSheep drops juicy bait for Firesheep (fake session cookies wrapped in legitimate-looking requests to sites) and waits for Firesheep to pick them up. When a Firesheep attacker tries to exploit these fake insecure sessions, BlackSheep picks up on it and alerts its user.

While there are some Firesheep users that will set off this alarm, the problem is a bit more serious. Many attackers have probably looked deeper into the fundamental flaw and also want to protect themselves from such an attack. These folks will be using a security-forcing add-on like Force-TLS, STS-UI on Firefox 4, HTTPS Everywhere or NoScript. All of the protected bad guy's connections to vulnerable sites will be secure, including the sessions that have been copied from other users on the network.

The upshot is that while BlackSheep may see the attacker connecting to vulnerable sites, it won't always know when the bait was taken. For many serious Firesheep-like attacks, BlackSheep will remain quiet.

There are many Firesheep users who are just playing around with the new, hot hacking tool, and so BlackSheep will cry out some of the time; it can't however be relied on to detect most Firesheep attacks. While I like the idea of an alarm like BlackSheep, solving the underlying problem (and stopping serious attackers that are more of a cause for concern) is a bit more complex and requires a different approach. Ultimately, we need to secure wifi networks, protect ourselves with HTTPS-forcing technologies, and ask sites to protect their users by using HTTPS for the whole session.

Tuesday, October 26, 2010

Managing HSTS Data

I blogged about HTTP Strict-Transport-Security before and how it's all new and shiny in Firefox 4. With all the happy firesheep attacks on the horizon, it's made it even more important that sites start using HSTS.

In case you don't want to wait for your favorite sites to start deploying strict-transport-security, here's a way for you to enable it yourself. I whipped up a quick add-on proof of concept that lets you add and remove HSTS data.

There are two ways to manage HSTS data for sites using this add-on:
  1. Navigate to an HTTPS page, open the page info dialog, and tick the "Always access content from this site securely" box
  2. Choose the "Manage Strict-Transport-Security..." item from the Tools menu, and enter the host names for your favorite sites there.

Let me know what you think!

UPDATE: Instead of maintaining the add-on in parallel with Force-TLS, I've decided to adapt Force-TLS to use the HSTS bits built into Firefox 4 and show you the same UI. Instead of the STS-UI add-on, try installing Force-TLS!