Re: ISSUE-5: definition of tracking

On Sep 5, 2012, at 13:35 , Shane Wiley <wileys@yahoo-inc.com> wrote:

> The other issue here is that this language carries no context:
> 
> "Tell websites I do not want to be tracked."
> 
> With no context, why wouldn't every user click on this option?  What does "tracked" mean here? (the current debate)  Perhaps more importantly, how will clicking on this change my web experience?  Upside/downside/cost?  

Yes, indeed, we understand that if there isn't a real choice here (pluses and minuses on each side) it's pointless offering it as a choice. The documents currently do have +/- on both sides.

> 
> While not wanting to dictate the details of UI, I would hope we agree that context and links to learn more should be included with this choice (much like they should be included with exception requests).

I suspect that there is some degree of waiting for dust to settle going on here :-).

> 
> - Shane
> 
> -----Original Message-----
> From: Dobbs, Brooks [mailto:Brooks.Dobbs@kbmg.com] 
> Sent: Wednesday, September 05, 2012 11:47 AM
> To: Roy T. Fielding; Rigo Wenning
> Cc: W3 Tracking
> Subject: Re: ISSUE-5: definition of tracking
> 
> Roy,
> 
> If you are correct here, and I am not disagreeing, think what this means for attempts to obtain preference through language like: "Tell websites I do not want to be tracked".
> 
> Do we think that most users would interpret "websites" to mean only 3rd parties or might a reasonable person also think it meant that a 1st party e.g. medical/political/dating/younameit site might not "track" my UID (cookie, IP, whatever) as having visited?
> 
> There is a danger to defining words within a spec too far from their common meaning.  As it is likely to create the hurdle you point out below.
> 
> 
> -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 9/5/12 2:21 PM, "Roy T. Fielding" <fielding@gbiv.com> wrote:
> 
>> On Sep 5, 2012, at 9:04 AM, Rigo Wenning wrote:
>> 
>>> whether you exclude access logs from the initial definitions or 
>>> whether you cover them by permitted uses is just a matter of taste.
>> 
>> No, it is a matter of laws and regulations.  If a company says that it 
>> complies with the "Do Not Track" signal and the user has reason to 
>> believe (without reading *any* specification) that it means no access 
>> log will be retained past the current transaction, then the company can 
>> be held liable even if the specification says retention of the access 
>> log is permitted.  Fine text cannot overrule common perception when 
>> there is no expectation that a user will read the fine text (it isn't 
>> even presented to them as part of the standard, and certainly doesn't 
>> reflect current UI for the DNT configuration).
>> 
>> The purpose of a single, one or two sentence definition of what
>> DNT:1 means (and also what DNT:0 means) is so that it can be included 
>> in the UI, either directly or via tooltip/documentation, and thus 
>> become part of the nomenclature that can be reasonably understood by 
>> the user setting that config.
>> 
>> Furthermore, it allows us to make progress on the rest of the 
>> specification with a common understanding of what the specification is 
>> intended to accomplish, as opposed to what we just experienced on the 
>> call.
>> 
>>> So please do not use the definition for the access log argument. The 
>>> real question on access logs is the time of non-anonymized retention. 
>>> W3C anonymizes logs as a matter of policy after 6 weeks.
>>> This also helps with exuberant subpoenae. We can (and should IMHO) 
>>> discuss this explicitly instead of complicating the definition.
>> 
>> No, we can use fine print to further *restrict* the scope of retention, 
>> because the user is not going to complain about further constraints on 
>> what they have already permitted.  We cannot use fine print to broaden 
>> the scope to allow things that do not appear to be allowed by the 
>> definition.
>> 
>> ....Roy
>> 
>> 
> 
> 
> 

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Wednesday, 5 September 2012 20:40:09 UTC