Re: Intermediaries interfering with DNT decision making

On Sep 12, 2012, at 7:47 AM, Grimmelmann, James wrote:
> The text is ambiguous because the decision is ambiguous.  There never was consensus on whether this UI is permissible, only consensus on an ambiguous text that resolved simpler cases, but not this one.

Our charter forbids us from specifying UI requirements.  That does not
mean any of the following excerpts are ambiguous:

   A user is an individual human. When user-agent software accesses
   online resources, whether or not the user understands or has specific
   knowledge of a particular request, that request is made "by" the user.

   The goal of this protocol is to allow a user to express their personal
   preference regarding tracking to each server and web application that
   they communicate with via HTTP ...

   Key to that notion of expression is that it MUST reflect the user's
   preference, not the choice of some vendor, institution, or
   network-imposed mechanism outside the user's control. The basic
   principle is that a tracking preference expression is only transmitted
   when it reflects a deliberate choice by the user. In the absence of
   user choice, there is no tracking preference expressed.

   A user agent MUST have a default tracking preference of unset
   (not enabled) unless a specific tracking preference is implied by
   the decision to use that agent.

   We do not specify how tracking preference choices are offered to
   the user or how the preference is enabled: each implementation is
   responsible for determining the user experience by which a tracking
   preference is enabled. For example, a user might select a check-box
   in their user agent's configuration, install an extension or add-on
   that is specifically designed to add a tracking preference expression,
   or make a choice for privacy that then implicitly includes a tracking
   preference (e.g., Privacy settings: high). The user-agent might ask
   the user for their preference during startup, perhaps on first use
   or after an update adds the tracking protection feature. Likewise,
   a user might install or configure a proxy to add the expression to
   their own outgoing requests.

MSIE is a general purpose browser installed by default and required
for Windows update -- no choice is made by the user, let alone a
choice for higher privacy.

The express settings are not a choice for privacy, as is clear from
the other defaults under express settings.

If the user clicks through without reading the text in either express
or custom settings, the configuration is set "on" and results in sending
DNT:1.  In other words, the user has not made a deliberate choice and
the UA is violating two MUST requirements of the specification, in
addition to the recorded consensus on ISSUE-4 from Santa Clara,
detailed in Aleecia's message to the mailing list which was approved
by the entire working group (Jonathan abstained in the interest of
making progress, IIRC), and the subject of countless messages to the
group from industry that they will simply not implement DNT voluntarily
unless it reflects a user's deliberate choice.

Finally, these options that you claim are compliant are given to the
INSTALLER of IE/Win8 -- the first user created on the machine --- and
then applied to all users created thereafter.  It is not a dialog
presented to the USER on first use and does not match the suggestion
of an acceptable user choice in the last excerpt above.  In enterprise
environments, the installer and first user is usually not the same
individual as the "user" defined by compliance for later interactions
that send DNT:1.


As I've said multiple times now, if the WG disagrees with the text
in the spec, then the right way to do so is to object to the text
with a specific change proposal, in writing, on what must be changed
to resolve that objection.  Nobody has done that.

>  I could draft revised text to clean up section 3 and deal with this particular mess, but some members of the group will say that the revised text is consistent with the decision and others will say that it isn't.  It might be valuable to clean up section 3, but that will necessarily expose significant disagreements and inconsistencies in the "consensus" over what it means.

What matters for the final standard is the text in the spec, once
it has been approved by the working group.

>>> (2) Creates an obstacle to DNT adoption on the part of servers; and
>> 
>> How?  AFAICT, it is the only thing making it possible to deploy DNT
>> for Firefox and Safari (and other UAs that implement DNT correctly).
> 
> This patch is not necessary for deploying DNT for Firefox and Safari and other UAs, is it?

I mean deploy in general, as in convince sites that track that they
should implement DNT because the user really doesn't want tracking.

>>> (3) May cause serious regulatory trouble for server operators who do not realize their installation of Apache deliberately ignores IE 10.
>> 
>> The only regulations I know of in this space are regional, which continue
>> to apply after the signal is dropped.  In any case, the current compliance
>> specification already makes all HTTP servers non-compliant with DNT, so
>> that is not something a server operator can solve without further work
>> by the server developers or fixes in compliance.
> 
> I am thinking of any regulations based on truthful representations to consumers.  An operator who publicly claims to implement DNT but ignores IE 10 because of this patch takes a risk that the claim will be considered misleading.

First, it is impossible to truthfully claim to implement DNT given
that compliance isn't even defined yet.  Second, in order to be
compliant with what is in the compliance document now, a general
purpose HTTP server would require radical changes in data handling.
Third, no HTTP server right now distinguishes between first and
third party contexts, and none that I know of provide a tracking
status response that is a required indicator of compliance.
In short, the patch is the least of their worries, and easily
resolved by removing or commenting-out the lines.

And the notion that any "operator" can safely claim compliance
with DNT, without having full control and careful review of every
line of the server config, is laughable.  The config is run by root
and capable of publishing any and all data on the machine.

>  (Yes, this would require the regulator to reach a different conclusion than you have about IE 10's compliance or about a server's obligations in dealing with a noncompliant UA, but given the disagreements here, this is hardly out of the question.)

In any regional context that has privacy laws, those laws still
apply with or without the signal.

Maybe Ed Felten could answer the question for the FTC?  If the FTC
wants to provide any official guidance on this issue, I'll be happy
to forward it to the Apache PMC and conduct another vote.  The guidance
can be in private, if desired, but Apache dev votes must be public.

>  The alternative default -- honoring DNT requests that come from IE 10 -- creates no such risk.  If an operator wants to take the position that IE 10 is noncompliant and can be ignored, it is better for this to be an informed, "deliberate" choice by the operator.

The risk comes from claiming compliance while being clueless, not
from the default httpd.conf.

....Roy

Received on Wednesday, 12 September 2012 18:56:39 UTC