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