RE: extensions in Determining User Preference

Hash: SHA1

It's not about the validity of the signal, it's whether a server can be forgiven for  ignoring a DNT request that can be thought to be from a UA that does not offer an API to potential plug-ins. Whereas an API may be a good idea anyway this seems simply (another) delaying tactic by those that wish not to act on DNT signals. In reality it is becoming impossible to identify a UA anyway from request headers, this is likely to accelerate, and the whole question is moot.


> -----Original Message-----
> From: Dobbs, Brooks []
> Sent: 08 April 2014 21:30
> 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
> --
> 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.
> >
> >Regards,
> >
> >  Walter
> >

Version: GnuPG v1.4.13 (MingW32)
Comment: Using gpg4o v3.2.42.4591 -
Charset: utf-8


Received on Tuesday, 8 April 2014 21:21:19 UTC