Re: extensions in Determining User Preference


I'm pretty sure we didn't mean DNT to become a human rights debate about
who can represent choice for another.  I've always assumed this only
worked where the choice (or lack thereof) was meant to reflect the user at
the other end of the keyboard unless that user had knowingly agreed to
proceed through an intermediary with a preset choice - which again is a
defacto reflection of choice.  Your argument about a home router is a
slippery slope.  Again origin servers MUST proceed based on the choice of
the user (1, 0 or unset).  If a compliance doc gave rise to a specific
legal exception (i.e. cookie consent) based on a DNT:0 where that signal
was set by a router unknown to the user, I worry that we've lost a
defensible position of user choice.  This is not a property rights
argument; it is a technical spec about the conveyance of user choice.



Brooks Dobbs, CIPP | Chief Privacy Officer | KBM Group | Part of the
Wunderman Network
(Tel) 678 580 2683 | (Mob) 678 492 1662 |

This email  including attachments  may contain confidential information.
If you are not the intended recipient,
 do not copy, distribute or act on it. Instead, notify the sender
immediately and delete the message.

On 4/8/14 4:48 PM, "SULLIVAN, BRYAN L" <> wrote:

>The existing text reflects that no matter how originated, a signal must
>represent the choice of the user: "The basic principle is that a tracking
>preference expression is only transmitted when it reflects a deliberate
>choice by the user."
>What we must not do, is to limit the mechanisms of choice available to
>users. When I install a home gateway that sets a DNT header (or removes
>it, or whatever) according to my choice as the person responsible for
>setting policy in my house, I am exercising a right similar to that of
>enterprises to govern use of DNT through their proxies. I do have an
>obligation to explain the terms of internet service to users in my home,
>as enterprises provide employees with codes of conduct and other policies
>that apply to terms of employment. But beyond that obligation, I must
>have the freedom to provide internet service as I choose, in my private
>network. Users that choose to access internet services through it
>explicitly or implicitly agree to those terms. There are clearly
>mechanisms for explicit agreement (similar to how you accept terms of
>internet service at hotels before getting internet access) that can help
>ensure that users are aware of and consent to terms of use - and that
>represents their choice.
>Restricting my mediums of choice to the UA (meaning web browser
>specifically) is not providing me with choice. It is choosing for me.
>-----Original Message-----
>From: Dobbs, Brooks []
>Sent: Tuesday, April 08, 2014 1:30 PM
>To: Walter van Holst;; Shane Wiley
>Subject: Re: extensions in Determining User Preference
>To quote Rush, who were clearly thinking of DNT in 1980, "If you choose
>not to decide, you still have made a choice".
>No signal is as valid a choice as 1 or 0, and must be afforded the same
>protections. This is not a compliance issue; it is a technical one.  The
>technical spec must cover how a user choice is conveyed from client to
>server, which necessarily includes placing requirements on intermediaries
>such as plugins which may alter user choice (including the choice of not
>altering the default condition).  If the UA wants the benefit of
>representing an individual's choice, it hardly seems a mistake that it
>MUST take the responsibility of conveying and/or reacting to the actual
>choice of the individual.  Equally an origin server MUST NOT act on a
>signal which does not represent the choice of the individual.  Perhaps
>this is the "technical" part of the technical spec we should have been
>concentrating on?  That at least would have been something we could have
>tested implementations of.  If we wind up with a spec that effectively
>says a valid signal MUST reflect the choice of the user if originated by a
>UA and MAY reflect the choice of an individual set by an intermediary,
>then we've done a very poor job.
>Brooks Dobbs, CIPP | Chief Privacy Officer | KBM Group | Part of the
>Wunderman Network
>(Tel) 678 580 2683 | (Mob) 678 492 1662 |
>This email  including attachments  may contain confidential information.
>If you are not the intended recipient,
> do not copy, distribute or act on it. Instead, notify the sender
>immediately and delete the message.
>On 4/8/14 3:59 PM, "Walter van Holst" <> wrote:
>>On 2014-04-08 21:36, Shane M Wiley wrote:
>>> Walter,
>>> I agree that any technical standard that setups up compliance
>>> confirmation for the Server but not one for the signal setter is
>>> "pointless".  While we've done our best to introduce this disconnect
>>> in the WG process, it was ultimately decided to punt on this issue.
>>> Expect to see more on this in Last Call comments.
>>I maybe misreading, but this is not the reference I was asking for.
>>Also, on substance, I would say that any server that expects the user to
>>trust the server to adhere to whatever compliance spec the server claims
>>to adhere without trusting the user's expression of his or her tracking
>>preferences prima facie is a few clowns short of a circus.
>>> That said, while difficult, web browser compliance can be discovered
>>> in a lab.  We can install a web browser and a specific plug-in and
>>> observe the interactions to determine if there was compliance.
>>Such observation is meaningless since you cannot verify remotely what
>>plug-ins are active on a browser. So even if you have observed that a
>>certain browser and plug-in combo violate the rule you are suggesting
>>(with or without resorting to decompilation of both, which may or may
>>not be IPR infringement), you cannot reliably observe for a certain
>>interaction that that browser and plug-in combo is in play. Because
>>there is nothing that prevents a plug-in that already willfully inserts
>>a DNT:1 signal in the HTTP-requests to override browser preferences from
>>removing any evidence of its presence from any HTTP-requests and to
>>filter out any API-calls by fingerprinting Javascript. So from the very
>>start a completely pointless exercise. We all have much better things to
>>do than soiling this process with fundamentally senseless issues like
>>this. Just stop it.
>>  Walter

Received on Tuesday, 8 April 2014 21:06:22 UTC