Re: Intermediaries interfering with DNT decision making

> 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 submitted text already.

http://lists.w3.org/Archives/Public/public-tracking/2012Sep/0136.html

I propose text in the TPE in chapter 3 that is clear enough, for
example:

"Implementations of HTTP that are not under control of the user,
including Web Servers, MUST not drop or modify a tracking preference".


Rob


Roy T. Fielding schreef op 2012-09-12 20:56:
> 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 19:07:03 UTC