Original at the Stanford Center for Internet and Society.
Last Friday we submitted a comment to the FTC articulating our vision for Do Not Track. We expanded on a number of views already expressed on this blog: Do Not Track is about much more than behavioral advertising, an HTTP header is the right implementation, and Do Not Track is no threat to ad-supported businesses. Here are the new highlights. (For a fuller exposition of each, please see our comment.)
Defining Do Not Track
Beginning with process, there is a strong temptation to leap into precise definitions of Do Not Track. But any set of bright-line rules will incorporate distinctions that are controversial. The FTC should be vested with guided rulemaking authority to, in collaboration with stakeholders, develop bright-line rules. This is the standard model for regulation; Do Not Track should be no different.
Turning to substance, Do Not Track should be coextensive with the privacy concern it addresses: third-party tracking. Providing rulemaking guidance for Do Not Track thus requires establishing standards for “third party,” “tracking,” and exceptions.
Defining Third Party
In our view, the privacy distinction between first parties and third parties is shorthand for user expectations. An entity acts in a first-party capacity if a user reasonably expects to interact with it; it acts in a third-party capacity if a user does not. Relevant factors for user expectations include domain names, branding, and business relationships. In most cases resolving the standard is straightforward: The website the user visits is a first party; an advertising network or analytics provider is a third party.
The user’s remedy against third parties should, in the first instance, be coextensive with the privacy violation: Do Not Track should prohibit all data collection, retention, and use. Of course, the online ecosystem is quite complex, and we recognize that there will be a need for well-delineated exceptions where privacy concerns must reasonably give way to greater interests.
Exceptions to Do Not Track may be warranted when there is significant commercial need and privacy concerns and enforcement impact are minimal. We believe a two-step standard best captures this policy: First, legitimate commercial interests must substantially outweigh privacy and enforcement interests, and second, the means of achieving the commercial interests must have no greater privacy and enforcement impact than necessary. A number of tools are available for minimizing the privacy and enforcement effects of an exception, including client-side storage, dropping parts of data, secure hashing, retention periods, internal business controls, limited sharing agreements, trusted intermediaries, and audits.
Do Not Track Can Be Enforced
We envision two technical approaches to verifying Do Not Track compliance. First, most tracking at the application layer can be detected by modifying a browser to report tracking-related activity. For example, if after receiving a Do Not Track header third-party embedded content sets a unique cookie or lists the browser’s plug-ins, the third party may be violating Do Not Track. Second, behavioral advertising can be identified by monitoring ads for interest targeting. Data should be sourced using both crawling and crowdsourcing to ensure comprehensive coverage of top websites and a real-world sample of observations. We are beginning development of a Do Not Track verification system with colleagues in the Stanford Security Laboratory, and we look forward to sharing our work in the coming months.
Do Not Track Should Be Extended to Mobile Platforms
Third-party tracking is proliferating on mobile platforms; such tracking implicates the same privacy concerns as third-party tracking on the web, and likewise warrants a Do Not Track choice mechanism.
The Do Not Track header can be easily adapted to mobile platforms. Instead of a universal browser setting, Do Not Track should be a platform-wide preference that adds a Do Not Track header to all HTTP requests and provides a Do Not Track signal to apps. Much as embedded third-party web trackers would check for the Do Not Track header, embedded third-party mobile app trackers would check for the Do Not Track platform preference. Paralleling the granularity of the header, apps should be able to interact with the platform to request an exception from Do Not Track. As for verification, since third-party mobile tracking is heavily concentrated the problem is much simpler than in the desktop browser context.
Turning to policy, the first vs. third party distinction also seamlessly transitions to the mobile context. An app is a first party; a behavioral advertising network embedded in the app would be a third-party since its presence violates reasonable privacy expectations.
FTC Involvement is Necessary
When we initially articulated our vision for Do Not Track, we noted it could be implemented voluntarily or through industry self-regulation. We now believe legislation and FTC involvement are necessary.
In our view, third-party opposition to Do Not Track at a technological level is largely a façade. The HTTP standard is designed to allow flexible signaling with headers; Internet Explorer alone uses at least eight proprietary headers.
The substantive disagreements about Do Not Track arise from policy. A number of third parties oppose a stringent definition of third-party tracking. Given the diversity of online business models and businesses Do Not Track would affect, and given the consensus-based nature of the relevant trade associations, we believe voluntary comprehensive adoption will not occur. Moreover, as an empirical matter, the online advertising industry in particular has a track record of unsuccessful self-regulation.
The Federal Trade Commission is the right agency to define and enforce Do Not Track. The Commission’s growing technical staff lends it unique domain expertise for defining Do Not Track, and its capacity for and experience with consumer protection actions prime it to enforce Do Not Track.
The FTC received 439 comments on its draft privacy report. We strongly encourage reading the comments by our colleagues at the Electronic Frontier Foundation and the Center for Information Technology Policy.
We thank John Mitchell for his helpful feedback.