RE: Issue-207

Thanks Mike,

I think the last sentence is not making the TCS stronger and should be 
deleted. There is no argument yet besides (1) adoption rate and (2) 
costs (both raised by Shane), that would stop us from specifying 
restrictive normative language to strengthen the position of the user. 
The user could suffer from e.g., discrimination based on the use of (a 
certain brand of) technology, or just plain arbitrariness.

Since the TPE is kind of closed for now, I would rather prefer normative 
language in the TCM to pin down transparency, along the lines and 
reasons given in my previous posts.

Rob

Mike O'Neill schreef op 2014-04-17 23:14:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Only offering a list of reasons why the signal "might" be disregarded
> does not improve transparency and encourages arbitrarily ignoring of
> DNT. As there is no way to add qualifiers to the TSV we either have to
> 1) come up with a mechanism in the TPE to report qualifiers, or 2) add
> a further set of single character values to signal different disregard
> reasons, or 3) abolish the "D" signal or 4) reiterate the note in the
> TCS that a disregard response is assumed to be an exceptional event.
> 
> My vote would be for 3, i.e. Jonathan's point but if that is too
> radical we should at least do 4.
> 
> So:
> 
> A third party to a given user action that disregards a DNT signal MUST
> indicate so to the user agent, using the response mechanism defined in
> the [TRACKING-DNT] recommendation. (5.0 4th para)
> 
> Becomes:
> A third party to a given user action that disregards a DNT signal MUST
> [indicate its reason for doing] so to the user agent, using the
> response mechanism defined in the [TRACKING-DNT] recommendation. This
> specification is written with an assumption that disregarding DNT
> would only be used in situations that can be adequately described to
> users as an exception to normal behavior. If this turns out not to be
> the case, either the server's decision to disregard the signal needs
> re-examination, or this specification, or both.
> 
> Mike
> 
>> -----Original Message-----
>> From: Shane M Wiley [mailto:wileys@yahoo-inc.com]
>> Sent: 17 April 2014 20:24
>> To: rob@blaeu.com; Justin Brookman
>> Cc: W3C DNT Working Group Mailing List
>> Subject: RE: Issue-207
>> 
>> Rob,
>> 
>> The Working Group had originally agreed on two principles pre-W3C 
>> Staff/Co-
>> Chair "June Draft" Compliance document that I believe are in alignment 
>> with
>> your thinking here:
>> 
>> 1) If a Server is representing compliance then they must send the "D" 
>> response
>> when disregarding the user's signal, not simply disregard it.
>> 2) A Server must accompany a "D" response with a resource link to 
>> explain why
>> the user may be receiving the disregard response.
>> 
>> - Shane
>> 
>> -----Original Message-----
>> From: Rob van Eijk [mailto:rob@blaeu.com]
>> Sent: Thursday, April 17, 2014 12:02 PM
>> To: Justin Brookman
>> Cc: W3C DNT Working Group Mailing List
>> Subject: Re: Issue-207
>> 
>> 
>> Hi Justin,
>> Dear group members,
>> 
>> Having given this issue a bit more thought, I have come to the 
>> conclusion that
>> something needs to be added the discussion. I therefore request the 
>> issue to
>> remain open.
>> 
>> The TCS should IMHO include text that a party MUST provide information
>> regarding the specific reason for not honoring the user expression. A 
>> key
>> element, addressed in the TPE is that Tracking providers should not 
>> ever have to
>> second-guess a user's expressed Do Not Track preference. It is fair to 
>> say, that
>> users should not have to second-guess with regard to the D-signal 
>> (quid pro quo
>> principle). Just responding with 'D' would not be enough IMHO to 
>> fulfill the quid
>> pro quo. The user / user agent needs to know about the reason why the 
>> signal
>> got disregarded. The party's representation MUST be easy discoverable, 
>> clear
>> and unambiguous. It MAY be machine readable. The guiding principle 
>> IMHO, is
>> that transparency is key in the granular discussion between the user 
>> agent and
>> the server to prevent e.g., discrimination based on the use of (a 
>> certain brand of)
>> technology, or just plain arbitrariness.
>> 
>> I am trying to strike the right balance hear, and welcome your views.
>> 
>> Regards,
>> Rob
>> 
>> ---
>> Recital 66
>> 
>>  "Third parties may wish to store information on the equipment of a
>> user, or gain access to information already stored, for a number of 
>> purposes,
>> ranging from the legitimate (such as certain types of cookies) to 
>> those involving
>> unwarranted intrusion into the private sphere (such as spyware or 
>> viruses). It is
>> therefore of paramount importance that users be provided with clear 
>> and
>> comprehensive information when engaging in any activity which could 
>> result in
>> such storage or gaining of access.
>> The methods of providing information and offering the right to refuse 
>> should be
>> as user-friendly as possible. Exceptions to the obligation to provide 
>> information
>> and offer the right to refuse should be limited to those situations 
>> where the
>> technical storage or access is strictly necessary for the legitimate 
>> purpose of
>> enabling the use of a specific service explicitly requested by the 
>> subscriber or
>> user. Where it is technically possible and effective, in accordance 
>> with the
>> relevant provisions of Directive 95/46/EC, the user’s consent to 
>> processing may
>> be expressed by using the appropriate settings of a browser or other 
>> application.
>> The enforcement of these requirements should be made more effective by 
>> way
>> of enhanced powers granted to the relevant national authorities. "
>> 
>> Justin Brookman schreef op 2014-04-17 20:22:
>> > On yesterday's call, we discussed ISSUE-207 (Conditions for
>> > Disregarding (or Not) DNT Signals) against the Compliance
>> > specification.  Previously, some working group participants had argued
>> > that servers should never disregard or second guess DNT signals that
>> > are correctly formed (syntactically valid).  However, as we crafted
>> > the TPE, we explicitly provided for a mechanism that allows servers to
>> > signal to a user that they are disregarding the signal.  As adherence
>> > to TCS (or any other compliance regime) is voluntary anyway, there may
>> > no longer be an argument that TCS should prohibit disregarding certain
>> > DNT headers.  In any event, no one on the call yesterday expressed
>> > support for the previous change proposal to require servers to honor
>> > all DNT requests.
>> >
>> > If anyone wishes to argue for amending the TCS to require compliance
>> > with all DNT signals --- or alternatively thinks that TCS needs to be
>> > revised to make it more clear that servers have the option to send a D
>> > (disregard) signal --- please reply on the mailing list.  Otherwise,
>> > we will close the issue with no further edits as decided by consensus
>> > in two weeks.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (MingW32)
> Comment: Using gpg4o v3.2.42.4591 - http://www.gpg4o.de/
> Charset: utf-8
> 
> iQEcBAEBAgAGBQJTUERCAAoJEHMxUy4uXm2JdnUIAIF3hoyZBdngzbNhncg+6Uuu
> OxR+eo9Mw4hwqF6c5arHZb3VdPB8pJSpj6xOPci4EG57mCdkk4B4Cy0LPjWdrusk
> rKpSnY4xJzp1xD8oDbGSE986YzB8DmbLiN16OdS7Ax5GFZSyB375sM+rI2spnzD0
> x50C8b00E5ZdZ4w3Le3uN4sBgxZJARCHUR2uxqtepSM6Kgk2RzyAVW0y8fnOp55p
> hEAFu0aKH2L5j+2jKNWm26LppaO6QFY33rpuwVsxn75hC2NhDDhICapaqxG4HIf5
> MUjdLTViX95CYtYdgrYdU7UGvkP1VYu7yyetwkUKIZp/CVBEWYjbxv6ugFmP1m8=
> =SYu8
> -----END PGP SIGNATURE-----

Received on Thursday, 17 April 2014 21:28:42 UTC