RE: [w3c/dnt] Add more meta data in the Tracking Status Resource (#22)

David,

I was referring back to your post of the 23rd suggesting API store calls could be additive, with different detailURI and explanationString to specify purpose.

Without being able to match them up it would not be possible to revoke exceptions for a restricted set of purposes, or confirm a particular set's existence. Since all purposes would have to be treated as a unit, there would not be much point in differentiating them in that way.

The original definition with the confirm and remove calls using a "propertyBag" dictionary derived from the store one, would have kept this open as a possibility.

The same goes for arrayOfDomainStrings. A remove call with that in its dictionary could have removed a specific set of domains from a site-specific target list.

UA UI could give users that ability (to revoke atomic subsets), but the way the API is defined now that cannot be offered by sites.

Mike






-----Original Message-----
From: singer@apple.com [mailto:singer@apple.com] 
Sent: 13 June 2017 23:07
To: Mike O'Neill <michael.oneill@baycloud.com>
Cc: TOUBIANA Vincent <vtoubiana@cnil.fr>; Roy T. Fielding <fielding@gbiv.com>; Rob van Eijk <rob@blaeu.com>; public-tracking@w3.org
Subject: Re: [w3c/dnt] Add more meta data in the Tracking Status Resource (#22)


> On May 28, 2017, at 9:06 , Mike O'Neill <michael.oneill@baycloud.com> wrote:
> 
> I just worked on the draft TPE in github (to fix the site-wide indication bug)  and see that the remove* and confirm* calls now have their own PropertyBag dictionary (they used to derive from a template).
> 
> There is now no way to specify which storeSiteSpecific* call you want to cancel.

That was intentional; the point of the ‘remove’ calls was to return to a clean slate.

> A remove* would have to apply to all exceptions for that domain.

exactly. clean slate

> The confirm call still has an  arrayOfDomainStrings in its dictionary so you could differentiate between exceptions with different sets of domains, but not in the remove* call. Also If you wanted to specify a different purpose in the "explanationString", you cannot cancel or confirm a specific purpose.
> 
> Editorial: there is a sentence about arrayOfDomainStrings in the confirmSiteSpecific call that refers to storing an exception  so makes no sense here, it should be removed.
> 
> 
> 
> -----Original Message-----
> From: singer@apple.com [mailto:singer@apple.com] 
> Sent: 23 May 2017 19:14
> To: TOUBIANA Vincent <vtoubiana@cnil.fr>
> Cc: Rob van Eijk <rob@blaeu.com>; public-tracking@w3.org (public-tracking@w3.org) <public-tracking@w3.org>
> Subject: Re: [w3c/dnt] Add more meta data in the Tracking Status Resource (#22)
> 
> I am not sure what you mean.  A site can make several different, additive, calls with different explanation strings (and one assumes different targets).
> 
> Sent from my iPad
> 
>> On May 23, 2017, at 11:12 AM, TOUBIANA Vincent <vtoubiana@cnil.fr> wrote:
>> 
>> 
>> 
>> Yes that works to inform the user, but I'm not sure you can store the exception and the information in the browser.
>> ________________________________________
>> De : singer@apple.com [singer@apple.com]
>> Envoyé : mardi 23 mai 2017 17:44
>> À : TOUBIANA Vincent
>> Cc : Rob van Eijk; public-tracking@w3.org (public-tracking@w3.org)
>> Objet : Re: [w3c/dnt] Add more meta data in the Tracking Status Resource (#22)
>> 
>>> On May 23, 2017, at 1:10 , TOUBIANA Vincent <vtoubiana@cnil.fr> wrote:
>>> 
>>> Hi David,
>>> 
>>> As Rob mentioned it would be very helpful if publisher could store multiple site specific exceptions, one for each category. However, my understanding is that site-specific-exceptions are stored as duplets [origin, target] or [origin,*] so it is not possible to record an exception for a purpose.
>> 
>> Ah but you can explain; there is
>> 
>> explanationString
>> A short explanation of the request.
>> 
>> in every request.  Since it’s just to explain to the user, this would seem to suffice.
>> 
>>> 
>>> We may have to store triplets instead [origin, *, category] but that's not a minor change I guess.
>>> 
>>> Best regards,
>>> 
>>> Vincent
>>> 
>>> -----Message d'origine-----
>>> De : singer@apple.com [mailto:singer@apple.com]
>>> Envoyé : vendredi 12 mai 2017 16:38
>>> À : Rob van Eijk <rob@blaeu.com>
>>> Cc : public-tracking@w3.org (public-tracking@w3.org) <public-tracking@w3.org>
>>> Objet : Re: [w3c/dnt] Add more meta data in the Tracking Status Resource (#22)
>>> 
>>> 
>>>> On May 11, 2017, at 22:39 , Rob van Eijk <rob@blaeu.com> wrote:
>>>> 
>>>>>> So, I am having a hard time with finer-grained exception handling on both ends — unlikely to be used at the UA, and unlikely to make sense for sites. Why do we keep exploring it?
>>>> 
>>>> In Europe most sites allow for granular consent based on categories of embedded 3rd parties, e.g.,
>>>>    • Functional cookies
>>>>    • Analytics
>>>>    • Social media
>>>>    • Advertising cookies
>>>>    • (Re)targeting cookies
>>>> Would the publisher still be able to allow for such granularity based on the current text in the TPE?
>>> 
>>> Yes.  If the publisher has more than one ‘bundle’ of third parties, it can call the exceptions API multiple times, to store site-specific exceptions (a) for my advertisers (b) for my social media connections, etc.
>>> 
>>> In each case, it knows it either has the complete requested exception granted, or not; there’s no partial exception. Either I have advertising tracking go-ahead, or I don’t.
>>> 
>>> 
>>>> 
>>>> Rob
>>>> —
>>>> PGP id: CC4F3863 [public key]
>>>> PGP fingerprint: 1D00 A9FD 7CCB A5A5 850E 2149 BEA0 20B7 CC4F 3863
>>>> 
>>>> Social media: @rvaneijk, github, linkedin, ssrn, stackoverflow.
>>>> 
>>>> 
>>>> -----Original message-----
>>>> From: David Singer
>>>> Sent: Friday, May 12 2017, 12:28 am
>>>> To: public-tracking@w3.org (public-tracking@w3.org)
>>>> Subject: Re: [w3c/dnt] Add more meta data in the Tracking Status Resource (#22)
>>>> 
>>>> 
>>>>> On May 11, 2017, at 9:39 , Mike O'Neill <michael.oneill@baycloud.com> wrote:
>>>>> 
>>>>> Matthias,
>>>>> 
>>>>> The user can already "choose to constrain an exception to a subset of third parties" if the server allows him to.  That is what the arrayOfDomainStrings parameter is for.
>>>>> 
>>>>> At the moment, because the TPE must enforce "one out, all out", the user agent in its own UI can only allow the user to change what has been established during their interaction with the server by revoking all of them at once. It cannot allow the user to selectively change the set of third-parties once they are granted.
>>>> 
>>>> Agreed. I also think that the likelihood that a UA will want to offer a finer-grained UI is very small. Let’s look at cookies: Firefox allows you to delete individual cookies, but Safari only offers ‘all for a site’ and as far as I can tell, Chrome only offers ‘all cookies and other state from all sites for the past N hours’.
>>>> 
>>>> I also have trouble imagining how a site would ‘feel’ if it says “look, for you to get free access I need tracking for <these advertisers> and <these audit companies>”, and you say ‘ok’ but then send DNT:0 only to the audit companies.
>>>> 
>>>> So, I am having a hard time with finer-grained exception handling on both ends — unlikely to be used at the UA, and unlikely to make sense for sites. Why do we keep exploring it?
>>>> 
>>>> 
>>>> Dave Singer
>>>> 
>>>> singer@mac.com
>>>> 
>>>> 
>>> 
>>> David Singer
>>> Manager, Software Standards, Apple Inc.
>>> 
>>> 
>> 
>> David Singer
>> Manager, Software Standards, Apple Inc.
>> 
> 
> 

David Singer
Manager, Software Standards, Apple Inc.