Re: My understanding of the controversial discussion / Discussion towards a Call for Objection text.

My core issue is that this addition complicates (breaks) existing processing mechanisms in the TPE: site-wide exception vs. no exception.  
At its essence this could be seen as an attempt to reintroduce a form of a "Tracking Protection List" which the group has already abandoned.  
If implemented, it appears the goal of this field is to block or send DNT:0 to 3rd parties that are not included in the list (automated processing).  
If the goal is transparency, would it be acceptable to provide this field but instead of a static list of third parties we would ask that a URL be provided to the end user to read at their leisure?  This will allow for more complex assemblies and linked disclosure systems (to cover exchanges).  This also avoids the application of machine read elements that disintermediate the publisher and 3rd party from the end user during the consent discussion.  To Rob's earlier points I believe there are many valid/legal approaches to providing specific and informed disclosures in the pursuit of consent - not a singular path through a static list.
If the goal is control, I disagree with this path - even as optional as it will add unneeded complexity to both user agents and publishers.  For example, if a publisher has registered a "site-wide exception" and doesn't provide this list or provides only a partial list - how do they learn if one of their 3rd parties received a DNT:0 when it was their expectation they would receive an DNT:1?  It will be in those scenarios that the publisher will need to re-engage with the user such that their 3rd parties receive the expected signal going-forward (meaning MORE pop-up dialogue boxes - not fewer).  We should avoid any scenario where the user agent is somehow expected to develop their own consent flows on behalf of another party as they will not be able to appropriately inform the user the nature, scope, purpose, and uses that will come with that consent (no upside; considerable risk downside for the UA vendor).
- Shane Shane Wiley
VP, Privacy Policy
Yahoo

      From: Matthias Schunter (Intel Corporation) <mts-std@schunter.org>
 To: "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org> 
 Sent: Tuesday, April 25, 2017 5:43 AM
 Subject: My understanding of the controversial discussion / Discussion towards a Call for Objection text.
   
sDear WG,

I gave the issue some more thought and re-read some of your emails. I
believe that I now better understand what the controversy is about. This
email tries to unpeel its layers to discover what the CfO should be about.

Please correct me if I am wrong.

-- Level 1 --
The question (on the foreground is):
(A) Should we include an optional field "other-parties" that allows a
site to list some parties it uses.
(B) or not

-- Level 2 --
The next deeper level (as I understand it) is:
(A) A site should list all resources in a machine readable form to allow
transparency in a EU context.
(B) We have a site-wide exception (all parties loaded by a given first
party receive DNT;0); there is no need for a machine-readable list anywhere.

-- Level 3 --
Note that we allow site-specific exceptions. Those could be used by a
site to publish all third parties that it uses. A site-specific
exception already allows a site to list as many sub-domains as it likes
(I am talking about the site-specific variety where you can include
cookie-patterns for third parties; not the site-wide that does not
contain patterns for third parties).

So the second layer as I see it:
(A) TPE should provide a standard that enable a site to list all its
resources/urls in a machine-readable format _that can be discovered up
front_ (e.g. in the TSR) if the site desires to do so.
(B) TPE must not enable a site to publish a list of its third party
resources/urls in a machine-readable format.

-- Level 4 --
So after all, it seems that the fundamental disagreements are as follows:

So the final layer as I see it is:
(A) TPE should enable a site to list all its resources/urls in a
machine-readable format _that can be discovered up front_ (e.g. in the
TSR) if the site desires to do so.
(B) TPE must not give the market this choice and must not enable a site
to publish a list of its third party resources/urls in a
machine-readable format.

I would like to receive your feedback whether this is indeed the core
question that we decide with the upcoming CfO.

If yes, the CFO question could be phrased like this:
    "To what extent and in what form should TPE allow a site to publish its
third party resources in a machine readable form?"

This question is intentionally a bit more open to allow answers like
"all sites must always" "no site is allowed to ever" and all the
different shades of grey in between...

In the first phase, I would call for alternative proposals. In the
second phase we would then call for objections.

What do you think? Any feedback is welcome. Also proposals on how to
reach consensus without a CfO are highly appreciated.


Regards,
matthias


----

BACKGROUND: Some Legal Opinions that I heard (that I do not like to
discuss):
- Some believe that all third parties must be known to the user to give
valid ("specific") consent in the EU
- Some believe that this must be machine readable (e.g. listed in the
exception)  to be useful in an EU context
- Some believe that this must be discoverable up front (e.g. in the TSR)
- Others disagree