If you followed privacy developments last week, you might have had the mis-impression that Mozilla is about to build Do Not Track technology into Firefox. In fact, the real news comes this week, as Microsoft announced that Internet Explorer 9 will include a very refined Do Not Track option for consumers. This will provide verifiable control over how their browser interacts with, and can be tracked by, data and ad companies. By embracing this approach for the world’s most popular browser, this immediately changes the game for all browsers and for the Do Not Track effort.
Two months ago at PrivacyChoice we embraced this approach by launching TrackerBlock for Internet Explorer. Our service uses similar (but less refined) technology already built into the current version of Internet Explorer, combining it data from the Tracking Company Index, the only comprehensive public list of tracking domains (which we have been curating for nearly two years). By downloading our XML file and importing it into their browser, the user can selectively block the use of third-party cookies from tracking companies, without impairing less-controversial uses of cookies from other domains. (We have an API for our domain lists that we’re happy to make available for organizations who want to start building blacklists and white lists – please contact us if interested.)
Microsoft’s new approach goes further in four important ways: (1) it takes blocking beyond just cookie access to other potential tracking interactions; (2) it provides more refined controls (white lists and blacklists tailored for specific purposes); (3) it allows third parties to create lists based on their own recommendations for consumers; and (4) it allows these curated lists to be automatically updated in browsers where they are installed.
Here are some key questions and implications from Microsoft’s announcement:
- Why would I only want a universal header if I can have this? Most of the discussion around Do Not Track so far has centered on a universal browser header that would transmit the user’s preference to every server it encounters. Because this feature doesn’t actually block anything, it provides no assurance for consumers, and puts a greater burden on back-end auditing of compliance. With Microsoft’s announcement, it’s hard to see lawmakers and regulators accepting the idea that consumers should just transmit their preferences into the void; instead, they should have verifiable control.
- How will people find it? Microsoft has already said that the blocking feature will be “off” by default (not a surprise). So how will consumers find it? Will it be offered at startup? What consumers need is for this browser setting to be engineered so that web applications (like the enhanced notice that is being built into ads) can leverage it in an easy way to provide consumers with meaningful choice in context. In designing the TrackerBlock for IE experience we’ve learned this is not easy to do; but the native browser implementation could make it much easier.
- Do companies need to segregate tracking domains? Data companies and ad networks now need to think about how to segregate behavioral and non-behavioral activities onto separate domains or subdomains, so that whitelists and blacklists will not block advertising interactions that do not involve tracking. Ultimately this will lead to some kind of auditable certification process to ensure that non-tracking domains are not used for the wrong purposes. I expect standards to emerge — such as limited lifetimes for non-tracking cookies — that will make certification and auditing easier to do.
- What about performance? Several months back when Microsoft advised us on the implementation of TrackerBlock for IE, they pointed out that as the list of blocked companies grow, browser performance could become an issue. Some performance penalty may be acceptable, but with direct commitment from the browser companies, I expect smart engineers can avoid making consumers choose between performance and privacy control.