Following up on our December announcement, we’re now offering “tracking protection lists” for the new version of Internet Explorer. These lists activate internal tracking controls in IE9 that are easily installed, verifiably effective and can be activated in the context of any webpage or privacy notice. This new IE9 functionality is an important step toward a tracking-choice framework that empowers consumers while coexisting with the web ad economy.
Based on our experience so far in developing tracking protection lists (TPLs), I’m offering two suggestions for improvement.
1. IE9 should also include a Do-Not-Track header option.
Firefox allows a universal “do not track” header which, when activated, sends the opt-out preference with every server request made by the browser. While simple and potentially universal, unlike TPLs, do-not-track headers offer no assurance to web users that their preference will be honored. Nevertheless, it’s hard to see a downside in making the same feature available in IE9. It can live a menu (as in Firefox), or (even better) it can be installable from a webpage link like TPLs.
The two approaches are compatible, and potentially complementary. A generic do-not-track header is like a “Disallow” selection that is not limited to a particular domain. In the same way, the header would be trumped by any specific “Allow” elections, resolving potential conflicts. This hybrid approach gives users both generic and specific choices, which can be implemented directly in the browser or through tracking company processes.
Of course, the Do-Not-Track header relies on a definition of “tracking” to determine what kind of data collection is not permitted. This definition most likely will come from industry groups or regulators (more to come on that topic).
2. TPLs should shift the burden to tracking companies to specifically identify non-tracking data collection.
Tracking Protection Lists are powerful because they selectively block any interaction with ad delivery companies, even the serving of an image ad. But TPLs were not created for the purpose of blocking ads, but only to block behavioral data collection that may accompany ad delivery. The challenge for curating Tracking Protection Lists is in differentiating those interactions. There is no obvious way for a curator to block tracking but allow the display of contextually (versus behaviorally) targeted advertising, or to allow collection of non-tracking data like the number of times an ad has shown.
Only the tracking company knows whether a particular interaction involves behavioral data collection. They are in the best position to indicate when an interaction does not involve behavioral data. To enable this, we include the following logic in the PrivacyChoice TPLs:
- All interactions with a tracking company are presumed to be behavioral, and therefore disallowed, but
- Any interaction is allowed if the URL includes the string, “not_tracking”
This approach allows tracking and non-tracking activities to be sorted by the companies themselves, rather than by list curators. It also creates an express affirmation to the web user about how their data will or will not be used. This enhances enforcement, insofar as it would be deceptive to label an action as “not tracking” if it is actually otherwise.
The same self-identification approach can be applied when the Do-Not-Track election is implemented through headers, as in Firefox. Companies that recognize the header may still want to collect data through cookies for non-behavioral purposes. When they do so, a “not tracking” indicator should be part of each interaction.
In either case, this approach makes do-not-track more verifiable. It’s simple to test whether opted-out browsers experience any interactions that lack the “not tracking” indicator. When implemented as a subdomain (like “not-tracking.adcompany.com”), the user will see this in their browser cookie list, and can easily spot companies that haven’t provided the additional assurance.
Just as no companies currently recognize the Firefox Do-Not-Track header, no companies currently use “not tracking” strings. The power of the IE9 approach is that, unlike headers, by presumptively blocking they truly shift the burden to the ad companies to identify and control behavioral tracking activity, while still accommodating other ad targeting and delivery needs that are properly identified.