Original at the Stanford Center for Internet and Society.
Since our introduction of DoNotTrack.Us last week we’ve received a deluge of questions. This post answers some of the most common inquiries. If we haven’t covered an issue you’d like a response on, shoot us an email and stay tuned – more Q & A posts are in the pipeline.
Q: Do Not Track does not block third-party tracking. Wouldn’t that be a better solution?
Some privacy-conscious users block third-party tracking, most commonly through browser add-ons. This type of self-help is completely compatible with and complementary to Do Not Track; many Do Not Track users may elect to use blocking software. But blocking alone is not a complete solution to web tracking. Here are our chief concerns:
- Universal blocking is infeasible. Web security research (1, 2, 3) has uncovered dozens of means of tracking users; technical barriers to all these approaches are not practical. And a recent informal study of popular Firefox blocking add-ons suggests that blocking is, in practice, far from a universal opt out. Users should not be left guessing as to whether they’ve actually opted out of tracking.
- Blocking software requires perpetual development and user vigilance. There is frequent turnover of tracking services and tracking technologies. If a developer takes a break, its blocking tool will diminish in effectiveness. Users must, consequently, periodically ensure their blocking software is still maintained and up-to-date.
- Blocking inhibits third-party tools. A number of popular website tools and plug-ins are hosted by a third party that also tracks users. Blocking would disable these tools, while Do Not Track accommodates them.
Q: Would Do Not Track require users to opt out of all third-party tracking, on all sites?
No. Do Not Track users would have the ability to whitelist sites and tracking services by simply not sending the Do Not Track header (or otherwise signaling that tracking is permissible). Whitelist management is primarily a user interface problem; we look forward to creative solutions in this space.
Q: Ads provide important context and notice for managing tracking preferences. How would Do Not Track be linked to ads?
Linking ads, privacy notices, and other visible content to a user’s Do Not Track settings is certainly possible. A software interface (i.e. a protocol handler or JavaScript API) could facilitate querying the user’s Do Not Track settings and prompting the user to make changes.
Q: Would Do Not Track be enabled by default?
Do Not Track could be a default; this is up to browser vendors, legislators, and regulators. Owing to conflicting business interests and engineering demands, we find it unlikely the major browser vendors will voluntarily enable Do Not Track by default. We caution in general, however, against regulation of client software, which has historically proven challenging.
Q: How difficult would it be for a tracking service to implement support for Do Not Track?
We did not have difficulty implementing Do Not Track for popular web servers and web application frameworks. We believe tracking services will have a similar experience, though the business logic required may involve more effort.
Q: Does Do Not Track require the cooperation of browser vendors?
To support Do Not Track, a browser must at minimum provide an add-on API that allows header modification (we review browser APIs here). Browser vendors may also choose to implement Do Not Track themselves.
Q: Will older browsers be left out of Do Not Track?
Backwards compatibility is a challenge for any new web technology. We are aiming for as broad support for Do Not Track as is possible, but we recognize that a minority of older browsers may be left out.
Q: Is Do Not Track a modification to HTTP?
No. Custom HTTP headers are a component of the HTTP standard (see IETF RFC 2616).