RE: extensions in Determining User Preference

-----BEGIN PGP SIGNED MESSAGE-----
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.

mike

> -----Original Message-----
> From: Dobbs, Brooks [mailto:Brooks.Dobbs@kbmg.com]
> Sent: 08 April 2014 21:30
> To: Walter van Holst; public-tracking@w3.org; 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 | kbmg.com
> brooks.dobbs@kbmg.com
> 
> 
> 
> 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" <walter.van.holst@xs4all.nl> 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
> >
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
Comment: Using gpg4o v3.2.42.4591 - http://www.gpg4o.de/
Charset: utf-8

iQEcBAEBAgAGBQJTRGgcAAoJEHMxUy4uXm2J8p4IALcn+wWUxD7UD+/Hv0sDpEuG
5q6GLthOf+6aIlt0MdSJHF3uv0ynQ1yhyYk9ANzk48KPZ9D2zU7S3kPJlwRQ36Kk
DaQ+Ov6Lo6u3iuhaG+dyZf4oTJd0k1ZByR4Hrig1PeKLGmkiagEPc9jcUYFqB+pW
8T1wPC1IOGZ3BC+EBOcXz+j6kXGmxpe+KMUriXdznP4hHcm7S4fiNTXKLVi4LpAN
5XEI4dgotkMB9Cv20xDMo85R0zGzRgTpIhjgoorCO9kPzH8YOlzIyjMwoaGNQ561
Urb+qed5EQpskHIOTGJtpStCi08eYZexUMp1SfPypJmn7j8E9xB47rEs8RlD2WU=
=clA3
-----END PGP SIGNATURE-----

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