W3C home > Mailing lists > Public > public-tracking@w3.org > November 2012

Re: action-307, issue-119, absolutely not tracking

From: Ed Felten <ed@felten.com>
Date: Thu, 8 Nov 2012 12:18:53 -0500
Message-ID: <CANZBoGj+hZsbtvbn2-uAaqtxJZPumeeu-BTCMmm5omZa7dDJ0w@mail.gmail.com>
To: "Dobbs, Brooks" <Brooks.Dobbs@kbmg.com>
Cc: David Singer <singer@apple.com>, David Wainberg <david@networkadvertising.org>, "public-tracking@w3.org WG" <public-tracking@w3.org>
Brooks, perhaps there is a misunderstanding here.   I'm not trying to
inject any new requirements here, just to highlight Nick's point about the
implications of what has already been proposed.

Case 2 is my understanding of what Adrian et al were proposing--that a site
could engage in a permission dialog of some sort with a user, and if the
user gave permission then the site would use the new API to tell the UA
that the user had done so, causing the UA to send DNT:0 to that site in the
future.   I wasn't proposing that there be anything special about promises
that sites make to users during this process--they would be like any other
promise made by a site to a user.

Nick's point, as I understand it, is that if we are going to go down this
path, then we need to consider whether sites have the tools they need to
ensure that their actions toward a user are consistent with the promises
they have made to that user.


On Thu, Nov 8, 2012 at 12:02 PM, Dobbs, Brooks <Brooks.Dobbs@kbmg.com>wrote:

>   Ed,
>
>  Your case 2 introduces a huge new set of complexities and seems out of
> scope for the spec.  DNT: 0 means the same thing in both cases.  If "DNT:
> 0" and "DNT: 0" are to have different meanings then they need to be DNT: 0x
> and DNT: 0y.  If we need to go further to communicate the specific promises
> in  play to that site then you have DNT: 0 ;CP: CUR UNI…, but I don't thin
> there is a lot of appetite for that and I am pretty sure that is out of
> scope.
>
>  -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.
>
>   From: Ed Felten <ed@felten.com>
> Date: Thursday, November 8, 2012 12:38 PM
> To: Brooks Dobbs <brooks.dobbs@kbmg.com>
> Cc: David Singer <singer@apple.com>, David Wainberg <
> david@networkadvertising.org>, "public-tracking@w3.org WG" <
> public-tracking@w3.org>
> Subject: Re: action-307, issue-119, absolutely not tracking
>
>  I think this gets to a point that Nick raised on yesterday's call.
> Assuming that we adopt the new approach to user-granted exceptions (UGEs)
> that Adrian and others have proposed, there will then be two reasons that
> DNT:0 could be sent to a site.
>
>  Case 1: The user has expressed to the User Agent (UA) that they want to
> send DNT:0 generally.  In this case the UA is vouching that this is the
> choice the user has made, and the site can engage in tracking (to the
> extent allowed by law).
>
>  Case 2: The user has granted a UGE, and the site has implanted that UGE
> into the UA via the new API.  In this case the site is vouching that the
> user granted it a UGE, and if the site made any promises to the user in the
> course of asking for that UGE then the user can rely on those promises.
>
>  The UA knows which of the two cases it is in, but the site might not be
> able to tell the difference.
>
>
> On Thu, Nov 8, 2012 at 10:56 AM, Dobbs, Brooks <Brooks.Dobbs@kbmg.com>wrote:
>
>> David,
>>
>> Admittedly, I needed to start by looking up "bike-shedding", but, having
>> done so, I am not sure I agree.
>>
>> I think it would help us all to fully appreciate that UGEs aren't
>> exceptions to how DNT:1 is processed by a specific site; if an exception
>> at all, they are exceptions to DNT:1 being sent to ALL sites.  Isn't this
>> fundamentally different?  A UGE site has no way of knowing if they are "an
>> exception" or if the user's base line choice was to send DNT: 0 to all
>> sites.  I could imagine this having implications for sites that appear as
>> both 1st and 3rd parties.
>>
>> In any event, I think we ought to be as consistent and clear as possible.
>> Where something isn't an exception (or where the meaning of what it is an
>> exception to is unclear) we should fix the language.  Agree?
>>
>>
>> -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 11/8/12 10:33 AM, "David Singer" <singer@apple.com> wrote:
>>
>> >
>> >On Nov 8, 2012, at 16:30 , "Dobbs, Brooks" <Brooks.Dobbs@kbmg.com>
>> wrote:
>> >
>> >> Just as a point of clarification here I am noticing some language I
>> >> believe to be technically incorrect entering into the discussion.  To
>> be
>> >> clear - "short term collection" is NOT an exception; it is a permitted
>> >>use.
>> >
>> >sorry.  you are quite right.
>> >
>> >>
>> >> This actually highlights another issue.  For consistency we may need to
>> >> change the language around user granted "exceptions" because they
>> aren't
>> >> really exceptions.  An exception would be a special dispensation to
>> >> process a DNT: 1 signal differently than would otherwise be allowed.
>> >
>> >I have long felt that users give 'permission' (not 'exception') and that
>> >we need a different word for what the spec. allows in restricted
>> >circumstances (not 'permission' or 'exception').  But this is
>> >bike-shedding...
>> >
>> >
>> >David Singer
>> >Multimedia and Software Standards, Apple Inc.
>> >
>>
>>
>>
>


image_284_.png
(image/png attachment: image_284_.png)

Received on Thursday, 8 November 2012 17:19:37 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:38 UTC