Re: Issues for Monday Call

Hi Folks,

thanks for your inputs!

Some summary points that document my current understanding:
- AFAIK a side-wide exception only works in the EU if you can find out
who the third parties and potentially also find out some information
about their privacy practices (both not necessarily machine readable). -
Asking for wildcard consent (anyone on my page following whatever
practice) would not constitute informed consent in the EU. Thus
qualified site-wide exceptions (with well-defined third parties) are
likely to be required.
- Having a site-wide exception with a list of (discovered) third parties
and having each of these third parties pointing to a compliance
statement (via the TSR) should normally work.

This does not seem to work for ad auctions (where "unknown" (to the
publisher) parties out of a large pool may win the auction; listing the
hundreds of potential participants in the site-wide exception is not
feasible). For this specific use case, Rob sees a need for extensions of
the TPE. It seems that there is no current best practice how to conduct
ad auctions in a way that is likely to be compliant with upcoming
regulations.

There were some ideas floating around:
- one idea was a qualifier for ad-auctions (you can share my data
temporarily within an ad-auction).
- another idea was that the publisher can "extend" the site-wide
exception to the winner of the ad.

I hope that Rob will come up with a proposal that we can discuss during
our call that we can discuss. Otherwise, I would push the problem of ad
auctions to a future release.


Regards,
matthias





On 18.04.2017 20:23, Shane M Wiley wrote:
> Mike,
> 
> Disagree on your premise as I see a strong move to publishers using
> tools to discover 3rd parties on their sites (this is at the small/mid
> range - large publishers have been doing this for years for numerous
> reasons).
> 
> I was speaking to the Well Known Location (WKL) as not having a copy of
> the TSRO embedded within it.  Perhaps I need to reread the WKL
> construction description but I thought the TSRO was not a required
> element - but is something that is optional to point to from within the WKL.
> 
> - Shane
>  
> Shane Wiley
> VP, Privacy Policy
> Yahoo
> 
> 
> ------------------------------------------------------------------------
> *From:* Mike O'Neill <michael.oneill@baycloud.com>
> *To:* 'Shane M Wiley' <wileys@yahoo-inc.com>; rob@blaeu.com; 'Matthias
> Schunter (Intel Corporation)' <mts-std@schunter.org>
> *Cc:* public-tracking@w3.org
> *Sent:* Tuesday, April 18, 2017 2:16 PM
> *Subject:* RE: Issues for Monday Call
> 
> Publishers will often not have contracts with all their embedded
> third-party resources. I recently had an issue with a popular script
> library being delivered from a CDN where UID cookies were being
> inserted, and there was no way the publisher was even aware of them.
> Many sites have hundreds of third-party resources and can hardly have
> contracts with all of them.
>  
> For that reason I think site-wide [specific] consent will not be the
> norm. Publishers will not want to take on the risk of asking for
> informed consent for third-parties they are not even aware of.
>  
> BTW What do you mean by WKL (as opposed to the TSR)? The TSR lives in
> the WKL.
>  
>  
>  
>  
>  
>  
>  
> *From:*Shane M Wiley [mailto:wileys@yahoo-inc.com]
> *Sent:* 18 April 2017 15:46
> *To:* rob@blaeu.com; Matthias Schunter (Intel Corporation)
> <mts-std@schunter.org>
> *Cc:* public-tracking@w3.org (public-tracking@w3.org)
> <public-tracking@w3.org>
> *Subject:* Re: Issues for Monday Call
>  
> Rob,
>  
> This presumes that a publisher is unable to have direct relationships
> with 3rd parties under contract such that their site-wide exception is
> somehow not valid in your use case.  I believe this will NOT be the case
> in most scenarios based on current industry moves (from the earlier
> conversation, publishers will not want to have their user experience
> abruptly disintermediated due to DNT settings).  With that in mind, if a
> publisher has a site-wide exception from the user and this is registered
> with the browser, how do you ensure that state is not confused by the
> one you explain below?  It appears your model becomes valid if a
> publisher either (1) does not have a site-wide exception or (2) does not
> have a direct relationship with the 3rd party already disclosed in their
> consent.  
>  
> Additionally, each of the items you've called out, such as PURPOSE,
> could be covered by the WKL so why are those needed as separate elements
> in the TSR?  I'm still not seeing the value of the additional fields
> when we have a more expansive transparency tools available to publishers
> and 3rd parties already in place and available to data subjects at any
> point in the process once the domain is known to the browser.
>  
> - Shane
>  
> Shane Wiley
> VP, Privacy Policy
> Yahoo
>  
> ------------------------------------------------------------------------
> *From:*Rob van Eijk <rob@blaeu.com>
> *To:* Matthias Schunter (Intel Corporation) <mts-std@schunter.org>
> *Cc:* "public-tracking@w3.org (public-tracking@w3.org)"
> <public-tracking@w3.org>
> *Sent:* Monday, April 10, 2017 11:10 AM
> *Subject:* Re: Issues for Monday Call
>  
> Hi Matthias,
> 
>>>> 1. to tackle the question "what extra field and qualifiers do we 
>>>> need",
>>>> we now focus on the final open new use case which is online ad 
>>>> auctions.
>>>> Rob will report his findings and we see whether more info is 
>>>> essentially
> 
> The use case I am addressing is real-time bidding/programmatic
> advertising (hereinafter: RTB). RTB relies on a network of highly
> specialized parties. On the one hand we have parties collecting
> information through resources from the browser, on the other hand there
> are parties delivering resources to the browser. A resource could be
> anything ranging from an iFrame with a JavaScript for gathering usage
> and performance data to a web beacons for delivering UID cookies. The
> number of parties may vary per ad-network/ad-exchange. Some ad network
> are known for a higher number of parties interacting with the browser
> than others. Obviously, every network has its own strategic partners. In
> sum, RTB may be defined as a network of networks aimed at trading and
> delivering targeted ads. Typical specialized RTB-tasks are referrals,
> web analytics,  audience segmentation, personalization, or targeted
> advertising (See also the intro of the TPE).
> 
> If follows from the GDPR and the ePrivacy Regulation proposal that the
> information requirement of the GDPR applies to all RTB-parties. The
> purpose of the information requirement is to ensure fair and transparent
> processing. In fact, informed consent is not limited to the EU. Any
> jurisdiction where informed consent is the legal norm, the information
> requirement plays an important role. Indeed, as Roy pointed out, that
> would be a framework requirement, not a TPE requirement.
> 
> Therefore, in order to narrow the scope of the use case, it sees to (1)
> the direct interaction with the browser by RTB parties and (2)
> RTB-parties that cannot rely on OOBC or the consent by the publisher. My
> assumption is that the more real-time the informed consent requirement
> becomes, the more information needs to be readily available and
> presented to the user such that he/she can grant an exception.
> 
> The tracking status object contains properties that describe the
> tracking status applicable to the designated resource. Let's map the
> information required under the EU framework to the tracking status
> object:
> 
>   (a) the modalities of the collection => this is covered by the TRACKING
> property
>   (b) its purpose => => NOT COVERED by a tracking status property
>   (c) the person responsible for it  => partly covered by the CONTROLLER
> property. See suggestions by Mike [1]
>   (d) any measure the end-user of the terminal equipment can take to stop
> or minimize the collection => covered primarily by the TRACKING property
> itself, but also by the CONFIG, CONTROLLER, and POLICY properties.
>   (e) other information required under the GDPR where personal data are
> collected => mostly covered by POLICY property. WEBRESOURCES property is
> missing to inform the user about the recipients or categories of
> recipients of the personal data, if any.
> 
> In sum, from the analysis it follows that expressing the purpose needs
> more work. We should discuss (b) and (e). Possibly, a new qualifier
> property in the tracking status could do the job. In order to keep the
> TRACKING property clean, I prefer not to use DNT extensions. See alse
> the suggestions by Mike [1].
> 
> Regards,
> Rob
> 
> 
> [1] https://w3c.github.io/dnt/drafts/Transparency.html
> 
> 
> 
> Matthias Schunter (Intel Corporation) schreef op 2017-04-06 10:49:
>> Hi Folks,
>> 
>> 1. to tackle the question "what extra field and qualifiers do we need",
>> we now focus on the final open new usecase which is online ad auctions.
>> Rob will report his findings and we see whether more info is 
>> essentially
>> required to satisfy the "information" requirement by the EU 
>> legislation.
>> 
>> 2. We then look at the remaining high-priority issue:
>>  https://github.com/w3c/dnt/issues/13
>> 
>> 3. Then at the other lower priority issues
>> 
>> Our list of issues is at:
>>  https://github.com/w3c/dnt/issues/
>> Note that issues that are not resolved by end of April will be
>> auto-pushed out to potential future releases.
>> 
>> 
>> Regards,
>> matthias
>> 
>> -----
>> DISCUSSIONS FOR MONDAY
>> 
>> 1. Issue triage: Are there issues that are high priority and must be
>> resolved in April? If not, we can process without change.
>> 
>> 2. What additional fields are desired for simplifying compliance in the 
>> EU?
>> 
>> Note: So far I have not seen any submitted proposals for an additional
>> concrete field on the list. If I receive none, IMHO we can close this
>> discussion on monday.
>> 
>> 2. Best way to communicate "consent context".
>> Our current approach was that the TSR serves two roles:
>>     A. Discovery (before visiting site) of essential tracking
>>         information
>>     B. Sufficient context to give clear meaning to
>>         user-granted exception. This role triggered that we
>>         plan to require TSR if the exception API is used.
>>         It also fuels our discussion "what extra fields are
>>         needed"
>> Roy suggested that TSR may be the best place for (B). Let us see 
>> whether
>> we find a better place for the consent-context information.
>> One suggestion was that it should be part of the API call.
>> 
>> 3. Asyncronous API / Update Events (Continued)
>> https://github.com/w3c/dnt/issues/13
>> 
>> 4. Anything else we want to discuss
>  
> 
>

Received on Wednesday, 19 April 2017 06:36:48 UTC