I continue to disagree Bjoren. The important element here is the user. As long as the rejection of an invalid user agent request is made transparent to the user, then the entire purpose of the preference communication has been met (this is a communication between the user and the publisher/3rd party). I don't believe this is "complicated" as you phrase and instead is amazingly straight forward and clear to the user. If we create a standard where only 3rd parties have to be the responsible, good actor and user agents are able to be non-compliant at will and 3rd parties are still on the hook to honor the DNT signal, then we've created a standard hardly anyone will implement (massive corporate risk for no real avenue to move non-compliant UAs into compliance). I'll confer with others in industry in more detail, but I believe there is a very real risk that if we force honoring DNT:1 from invalid user agents, then no one will implement DNT at scale. Even P3P would have been more successful as a starting point...
- Shane
-----Original Message-----
From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net]
Sent: Friday, June 08, 2012 4:13 PM
To: Shane Wiley
Cc: ifette@google.com; public-tracking@w3.org (public-tracking@w3.org)
Subject: Re: Today's call: summary on user agent compliance
* Shane Wiley wrote:
>That is the sticking point here. The standard is voluntary but we still
>want a large majority of 3rd parties to implement DNT. If we require
>that supporting W3C DNT also requires accepting non-compliant UA
>signals, I can't see a reason why many, if any, 3rd parties would
>implement. If we're setting up a "failed start", then I'm at a loss for
>our path as a Working Group.
I think the DNT specifications need to say that the DNT signals can and
must be taken at face value, including the absence of such signals. If
you start with the second guessing, you will have to answer questions
why you exercise or reserve the right to second guess in one case but
not in some other case, and that will lead to pain and suffering.
I do not think there will be notable cases where user agents send non-
compliant DNT signals under normal circumstances; the user agent vendor
will rather argue that they are compliant, while others dispute that,
and there is currently no proposed mechanism to resolve that dispute.
It is possible that platform and browser vendors would be willing to
subject themself to some veto mechanism where they won't ship or revise
their user interfaces if tracking organizations do not like their user
interface decisions, which would resolve such disputes, but that's very
much out of scope of this Working Group as chartered, and not so likely.
I note that Internet Explorer 9 for instance will prompt users on first
use whether they accept, or not, or want to decide later, whether to use
the "recommended" security and compatibility settings. If Firefox had a
similar prompt and would throw in a DNT:1 recommendation in the dialog,
there would be similar complaints, even though I would find that in com-
pliance with any specification the Working Group could come up given its
limitations on making user experience requirements.
I do not think there is a big difference between that kind of prompt and
an outright default. Similarily, in the longer term, I would expect that
platform, read: operating systems, vendors will allow users to make more
"bundled" privacy decisions, like to turn on DNT for browsers and "apps"
running on the system. Someone feeling strongly about "privacy" may want
a general OS-level prompt they can use so applications stop asking them
if they are okay with sending crash reports, stop offering to particpate
in UI studies, stop storing their Wifi passwords in the cloud, and so on
and such a setting may similarily turn on DNT in the platform's browser.
The Working Group as currently chartered cannot make that obviously non-
compliant, so I see non-compliant DNT signals as a red herring for this
Working Group. As above, it would be better to simply define that DNT:1
is, by definition, the user's preference, and tracking organizations are
better off opposing DNT altogether if browser vendors make unreasonable
user interface decisions where DNT signals don't reflect user decisions.
There will be a Candidate Recommendation phase where the W3C calls for
implementations of the DNT proposals and the Working Group will evaluate
browser and "website" implementations of it, and compliance disputes, as
they are known by then, can be resolved, or not, at that point. That'd
be a better point to argue about possibly needed "escape clauses".
As I said earlier, if the Working Group cannot agree that "no means no",
it is unlikely that there will be a Recommendation; and I've listed some
of the options there are to turn "no means no" into "it's complicated".
As for the specific issue of a mainstream browser that is pre-installed
on a very large number of systems sending some DNT signal "by default",
well, if the vendor doesn't mind to say that it's a default (as opposed
to saying that users typically choose this browser explicitly because
it's known to offer "strong privacy protections" or whatever), require
them to make that explicit in the header and API. Let them send "DNT:23"
until users "manually" confirm this default. That gets you around "users
cannot activate DNT:1 explicitly in this browser" issue, and "browser
sniffing" issues, and would give services that honour "do not track" in
all cases an advantage over services that ignore "DNT:23" signals, pro-
vided they don't fall into the same conformance class (they should not).
--
BjÃ¶rn HÃ¶hrmann Â· mailto:bjoern@hoehrmann.de Â· http://bjoern.hoehrmann.de
Am Badedeich 7 Â· Telefon: +49(0)160/4415681 Â· http://www.bjoernsworld.de
25899 DagebÃ¼ll Â· PGP Pub. KeyID: 0xA4357E78 Â· http://www.websitedev.de/