httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Bug 53845] Remove DNT settings from httpd.conf
Date Thu, 13 Sep 2012 08:23:34 GMT

--- Comment #9 from Jonathan Mayer <> ---
The Apache community should be guided first by what the W3C Tracking Protection
Working Group has decided to standardize. The group has not deemed the final
Internet Explorer 10 Do Not Track implementation noncompliant, nor has it
sanctioned crude self-help in response to a noncompliant browser. That holds
true no matter which terminology is employed to describe the Internet Explorer
10 choice architecture ("preselected," "first-run," "install-time,"
"multi-user," "system-wide," ...).[1]

This change is procedurally and substantively problematic for myriad reasons.

1) It unilaterally and surreptitiously circumvents a legitimate, longstanding,
international, and multi-stakeholder negotiation.

2) It violates good software engineering principles by adding a special-case
configuration default that
a) almost always results in unnecessary processing,
b) is assuredly unexpected by most developers, and
c) blurs the layering of web application and web server.

3) It bars some shared-server developers of the ability to honor (or even
measure) an Internet Explorer 10 "DNT" header.

4) It renders Apache-based Do Not Track implementations noncompliant by
default, in the quite possible (if not likely) event that the Working Group
standardizes either
a) the Internet Explorer 10 implementation is compliant, or
b) a website may not ignore syntactically valid "DNT" headers from a
noncompliant browser.

5) Under the current Working Group consensus and draft text, Apache itself is
now noncompliant by default in a proxy configuration.

6) If pending proposals before the Working Group are accepted, it would make
Apache noncompliant by default in a conventional web server configuration.

7) It's bad policy to allow or encourage second-guessing syntactically valid
"DNT" headers. Every single user of a noncompliant browser would be stripped of
the Do Not Track choice. That includes users who have explicitly enabled Do Not
Track. In other words, this change would punish a user for the choices made by
his or her browser vendor. Website implementations would likely fragment in
which browsers they respect. In consequence, users, browsers, and policymakers
would lose the very consistency and trust that Do Not Track is intended to
promote. Likely outcomes include more common technical countermeasures by users
and browsers (e.g. ad blocking), as well as regulatory enforcement by U.S. and
EU authorities. There is, thankfully, a much better alternative: if a website
receives a "DNT" header from a noncompliant browser, it is welcome to politely
ask the user to confirm his or her preference.

8) One of the primary justifications for this patch, that there should not be a
privacy default, is internally inconsistent. This patch is precisely a privacy
default—it configures Apache to ignore certain privacy signals unless a
developer makes a change. Recall that in the absence of this patch developers
simply choose whether to honor Internet Explorer 10 "DNT" headers, either in
their application logic or in their configuration files. Without this change,
Apache does nothing to sway developers one way or the other.

I strongly urge the Apache community to reverse the change. Until that happens,
I expect that the Apache Software Foundation, the Apache community, Adobe, and
Roy Fielding will continue to experience intense criticism from researchers,
advocates, policymakers, and media. As far as I'm concerned, it couldn't be
more warranted.

That's all I have to say on this topic. Let's fix this and focus on
successfully concluding the Do Not Track negotiations.

[1] The Working Group has only agreed on one noncompliant user agent design: a
silent default in a mainstream browser. The final Internet Explorer 10
implementation is plainly not a silent default. A screenshot is available at

You are receiving this mail because:
You are the assignee for the bug.
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message