Re: Next 2 calls canceled (Oct 09 and Oct 16)

> On Oct 19, 2017, at 0:00 , Mike O'Neill <michael.oneill@baycloud.com> wrote:
> 
> David,
> 
> The coding should be visible to everyone i.e. in the TSR of each relevant third-party.

That’s fine, they can do that.

> There is then no need for an arbitrary coding table, and it is easy to automatically restrict the entropy.

sorry, if the code can be specific to that third party, and the explanation also is, then the conclusion is exactly the opposite: general definitions are not needed

> It would also be clearer if each extension is separated by a "&" and of the form {name}={value}, so extensions (there will be more than one eventually) can be in any order. This is the conventional way multi valued cookies are formatted (Microsoft style subkeys)

as I say, do it whatever way you like. we just provide a pass-through from the exception registration to the DNT header send

> 
> xTremeAnalyitics
> 0 = basic user data
> 1 = significant including residence zipc-code
> 2 = total including blood type, ancestry
> 
> https://xTremeAnalyitics.ru/.well-known/dnt/ returns
> {
>   Purposes: [
>      "basic user data",
>      "significant including residence zipc-code",
>      "total including blood type, ancestry"
>   ]
> }
> 
> If "basic user data" is selected, this is indicated by:
> DNT: 0&p=1
> 
> 
> xTremeAdvertizer
> 0 = abstract, meaning only rough delineage of my purchasing
> 1 =  quantity, meaning allows them to collect exactly what and how much
> 2 = inspected, meaning that they can collect things I only looked at, or seemed to hover over
> 
> https:// xTremeAdvertizer.cz /.well-known/dnt/ returns
> {
>   Purposes: [
>      "abstract, meaning only rough delineage of my purchasin",
>      "quantity, meaning allows them to collect exactly what and how much",
>      "inspected, meaning that they can collect things I only looked at, or seemed to hover over "
>   ]
> }
> 
> If "quantity" and "inspected" is selected, this is indicated by:
> DNT: 0&p=6 
> 
> 
> 
> -----Original Message-----
> From: singer@apple.com [mailto:singer@apple.com] 
> Sent: 19 October 2017 00:03
> To: Shane M Wiley <wileys@oath.com>
> Cc: Aleecia M. McDonald <aleecia@aleecia.com>; public-tracking@w3.org (public-tracking@w3.org) (public-tracking@w3.org) <public-tracking@w3.org>
> Subject: Re: Next 2 calls canceled (Oct 09 and Oct 16)
> 
> Hi Shane
> 
> I wonder if we can solve this with an optional DNT-extension string after each host name in the array when a site-specific grant is requested.
> 
> So, I interact first with my partners, and I agree with each of them what the DNT-extension string will mean. With xTremeAnalyitics, I agree that 1 means basic user data, 2 means significant including residence zipc-code, and 3 means total including blood type, ancestry, and so on. With xTremeAdvertizer, I agree that A means abstract, only rough delineage of my purchasing, Q means quantity and allows them to collect exactly what and how much, and I means inspected meaning that they can collect things I only looked at, or seemed to hover over.
> 
> I register for the site-specific exception with an other-parties explicit array
> 
> xTremeAnalyitics.ru;2
> xTremeAdvertizer.cz;Q+I
> 
> when the exception is registered, the UA record these strings and sends them as DNT extensions, i.e. it send
> 
> DNT:0;2 to xTremeAnalyitics.ru
> and
> DNT:0;Q+I to xTremeAdvertizer.cz
> 
> Yes, life for the site gets easier if all these third parties use a common grammar, but it’s not needed. It really helps if the first party can register
> 
> *;absolute
> 
> and know that the extension ‘absolute’ will be understood (the same way) by every third party conceivably embedded on it.
> 
> 
>> On Oct 13, 2017, at 21:20 , Shane M Wiley <wileys@oath.com> wrote:
>> 
>> David,
>> 
>> The way this is likely going to work in the real-world, with or without DNT, is that the publisher will be capturing the consent (by purpose) for each ad tech vendor they work with.  Imagine a consent dialogue that lists 5 ad tech partners with 2 to 3 purposes below each partner that the user must consent (thus far the mocks I've seen are not very pretty).
>> 
>> Note - I'll avoid the pre-checked box debate here as there could be a secondary unchecked box that confirms the user's choice prior to allowing them to hit the "I Consent" button.
>> Note 2 - I'll avoid the all-or-nothing discussion here (having that with Rob on the same thread).
>> Note 3 - I'll also avoid the pay-wall or tracking-wall debates (as those are on-going in the ePR legislative process).
>> 
>> The publisher will capture this consent and then need to convey it to those 3rd parties in some manner.  DNT is a nice solution as the browser does this for the ad tech vendor (publisher -> browser -> ad tech vendor).  Similarly, the publisher could daisy chain through their 3rd party ad tech vendor's domains (iFramed) so they each set a cookie with the appropriately passed parameters for what level of consent has been provided.  If the consent is "web-wide" the publisher would need to follow a similar approach anyway (site-wide does not require the iFrame daisy chain).  The publisher will of course record this themselves as any changes (new partners, new purposes) will require they interact with the user again to gain consent for the new elements.  Net-net: EU users will be seeing A LOT of consent dialogues going forward.
>> 
>> In the publisher to ad tech vendor setup they will need to agree to the purposes for which the ad tech vendor is seeking to gain consent to prior to launching the consent experience with users on the publisher's site.  Ad Tech Vendors may agree to a single set of possible purposes such that numbering is common across industry (1 = interest based ads, 2 = cross-device mapping, 3 = probabilistic mapping, N...).  In either case the publisher and the ad tech vendor have to agree to this up front so they are accurately conveying the appropriate consent for each purpose for that vendor.
>> 
>> - Shane
>> 
>> On Fri, Oct 13, 2017 at 9:39 AM, David Singer <singer@apple.com> wrote:
>> 
>> 
>>> On Oct 13, 2017, at 17:48 , Shane M Wiley <wileys@oath.com> wrote:
>>> 
>>> David,
>>> 
>>> The missing element in your assessment is that the user MUST be able to consent (or not) to the options individually.  We're not able to make it an "all-or-nothing" proposition legally.  If that was possible we wouldn't need to have this conversation as then a single signal would cover our needs.
>> 
>> OK. Kinda weird. The site may not do the quid-pro-quo (e.g. free access) unless you consent to it all.  So ‘granular consent’ as I wrote below, and possibly ‘changing purposes over time’ are both issues.
>> 
>> It’s easy for the site to talk back to itself; cookies, or even as I suggested using the DNT-extension. That covers the web-wide exception, and the site itself for site-specific.
>> 
>> How do you think a site should convey to the ads and its 3rd-parties, for site-specific exceptions, which purposes they have consent for?
>> 
>> “This user agreed to a non-vegetarian meal” “This user agreed to wearing synthetic fibers during the night-time” and so on?
>> 
>> 
>> 
>>> 
>>> - Shane
>>> 
>>> On Thu, Oct 12, 2017 at 11:33 PM, David Singer <singer@mac.com> wrote:
>>> 
>>> 
>>>> On Oct 13, 2017, at 0:20 , Shane M Wiley <wileys@oath.com> wrote:
>>>> 
>>>> I believe this is an over simplification of the issue.  If we want DNT to meet the most basic needs of even small publishers that means they will need to support at least one ad tech partner (assuming the goal of the group is still to meet the original target of the standard).  Even the most basic ad tech partner will participate in at least two distinct purposes which lawyers are expressing need to be consented to separately: interest-based advertising and cross-device mapping (all ad ecosystem participants support these two common approaches in the EU marketplace today).  If the DNT standard is unable to support even the most basic consent scenario then there will likely be zero adoption - at least for the most common use case and original target of the standard.  There may still be hyper edge cases where a singular purpose consent will cover all needed business cases.
>>> 
>>> Shane
>>> 
>>> I think I am confused.
>>> 
>>> When consent is requested, the site manages the UI. It can certainly ask:
>>> 
>>> I need to be able to track you so that
>>> * I serve you the breakfast that corresponds to your weird food fads
>>> * I and my third parties can gather data about you that I will sell to a foreign intelligence service, to cover my medical bills
>>> 
>>> So, the dual purposes can be clearly expressed in the request.
>>> 
>>> Likewise they can be expressed in the tracking status resource; we could certainly have a list of purposes added here:
>>> 
>>> object {
>>>   string tracking;                 // TSV
>>>   array { string; } compliance?;   // hrefs
>>>   string qualifiers?;              // compliance flags
>>>   array { string; } controller?;   // hrefs
>>>   array { string; } same-party?;   // domains
>>>   array { string; } audit?;        // hrefs
>>>   string policy?;                  // href
>>>   string config?;                  // href
>>> }*;
>>> 
>>> So, as I see it, for an unchanging picture we seem to be covered, no?
>>> 
>>> The tricky parts come in at least two ways:
>>> * if the site offers granular consent, for each purpose separately, it needs to know who consented to which purpose.
>>> * if the site’s needs and hence purposes for tracking change over time, it needs to remember “this user gave consent before I added purpose-Q, whereas that user gave consent also to purpose-Q”
>>> 
>>> Are these what we are struggling with?
>>> 
>>> 
>>>> 
>>>> - Shane
>>>> 
>>>> On Thu, Oct 12, 2017 at 2:47 PM, Aleecia M. McDonald <aleecia@aleecia.com> wrote:
>>>> 
>>>>> On Oct 12, 2017, at 11:16 AM, Shane M Wiley <wileys@oath.com> wrote:
>>>>> 
>>>> […]
>>>>> In either case, we'll need a purpose array for the ad industry to be able to leverage DNT as a lawful consent compliance approach in the EU (at least that's what EU lawyers are telling me).
>>>> […]
>>>> 
>>>> This sounds like an array of common purposes that also contains a purpose of other.
>>>> 
>>>> I imagine a common set of purposes congruent with EU regs, and then “other” managed entirely by the publisher, which defines what it means, conveys it meaningfully to users, and records not only consent but what was consented to. I would expect any given publisher using “other” to change what it means over time (e.g. after an acquisition or new product launch, etc.) which is why a timestamp is going to matter.
>>>> 
>>>> In an ideal world, Art 29 WP could issue guidance that turns the common set of purposes into something fairly self-serve. Perhaps there will be sample text akin to Safe Harbor guidance.
>>>> 
>>>> For the complexities of Other, well, see your local DPA to have a discussion about that.
>>>> 
>>>> Small sites should be able to do just fine with the common set. Large companies can get all the complexity they need from Other, which might need to be further defined as OtherA, OtherB, OtherC, on the backend, but that too is up to the publisher to manage.
>>>> 
>>>> Early on we had the idea that straight-forward publishers should be able to implement DNT easily and those with complex practices would have a more complex implementation. I think we can still fulfill that goal.
>>>> 
>>>> (I echo Rob’s concern about further delay and the ironies inherent in this discussion.)
>>>> 
>>>>       Aleecia
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> - Shane
>>>> 
>>>> Shane Wiley
>>>> VP, Privacy
>>>> Oath: A Verizon Company
>>> 
>>> Dave Singer
>>> 
>>> singer@mac.com
>>> 
>>> 
>>> 
>>> 
>>> --
>>> - Shane
>>> 
>>> Shane Wiley
>>> VP, Privacy
>>> Oath: A Verizon Company
>> 
>> David Singer
>> Manager, Software Standards, Apple Inc.
>> 
>> 
>> 
>> 
>> -- 
>> - Shane
>> 
>> Shane Wiley
>> VP, Privacy
>> Oath: A Verizon Company
> 
> David Singer
> Manager, Software Standards, Apple Inc.
> 
> 
> 

David Singer
Manager, Software Standards, Apple Inc.

Received on Thursday, 19 October 2017 15:59:09 UTC