RE: issue-170

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Roy,

What this is about is assigning a meaning to a UGE in an prior consent environment like the EU where a first-party server needs to be able to detect whether consent has been given (by a particular user). This is now implemented in a fairly widespread though ad-hoc way, usually with low-entropy cookies, and I imagine Rigo's motivation for his proposal was partly to leverage the existence of the DNT:0 signal to create transparency, but also to create the possibility for international consensus. 

The TPE already allows the use of the UGE when DNT is unset, for exactly this reason. I was attempting, admittedly somewhat clumsily, to incorporate Rigo's text for this within John Simpson's proposal. 

I have now withdrawn this sentence from my amendment, but will suggest new text covering the same point  to go into the UGE section of the TCS. 

But maybe I will wait till the dust settles on issue-170 and issue-219 first.

mike


> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@gbiv.com]
> Sent: 06 June 2014 18:56
> To: Mike O'Neill
> Cc: W3C DNT Working Group Mailing List
> Subject: Re: issue-170
> 
> On Jun 4, 2014, at 5:38 AM, Mike O'Neill wrote:
> > If a 1st Party receives a request with DNT:0 set then data regarding the user
> MAY be used or shared but, if the header signal resulted from an explicitly-
> granted exception, only for the purposes that were clearly and comprehensively
> explained when the exception was granted.
> 
> There is no need for this text.  If a server receives DNT:0,
> it will behave according to its own set of practices for DNT:0.
> It is not going to change its practices on a per-user basis.
> 
> If those practices exceed whatever the server might have stated in some
> request for a UGE, the server owner is inviting regulatory action or
> lawsuits.  We do not need to say anything about servers that mislead.
> 
> If the server does not request UGEs (and thus only receives DNT:0 when
> set web-wide), then it has no control over what was explained to the user
> and is instead relying on the browser configuration.  What the browser
> configuration means is largely outside the scope of compliance, though
> we all hope that they will eventually become consistent.
> 
> ....Roy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
Comment: Using gpg4o v3.3.26.5094 - http://www.gpg4o.com/
Charset: utf-8

iQEcBAEBAgAGBQJTkkNQAAoJEHMxUy4uXm2J6XUIAMVa1gEPmTU7t+4JySAEcWGu
0UTMFNms2RrTHdVGs22Jj8HN57Yom9lYPNWVwCtIuFEJDpir2ZMzGD0OGMJxAYIj
uEfdcbC0n8OWq7f3yq7CusrZNR34hw982KC2kZ8/zTFFAb/ClVI0ErKrKJMJ1Yi4
PDzZXOkhs4FxgF/6e6IUTC7ylLXdXG0TF/3PH4rmtx4CqGAt+pBirM8du4kBFyHp
OB4CyDmM+Ws7qPgSQnlLUPIgmoP37NUfRMu6YIkPHdRyp8daLeOFeR2+jpyGm3AD
9njaEF2YCF348UZYaEaMjGjsGiPZfYRGTiluN2/npLMjf3y/+S89+VxKdOt82Aw=
=wMfG
-----END PGP SIGNATURE-----

Received on Friday, 6 June 2014 22:41:04 UTC