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

Hi Matthias,

Thank you for the sharp analysis. I believe that in order for consent to be specific, sites are required to list their embedded resources and resources called as a result of visiting the site. Some resources are introduced by the controller, not being same party. Informed consent requires a list of all resources for it to be valid. I believe some EU sites will want to list all resources and therefor introduce a new TSR property. The new field contributes to the transparency principle. I believe that the new field benefits both site owners wishing to rely on site-wide consent as well as other-parties seeking site-specific consent. Since the normative element is a MAY the additional property remains optional. 


My text proposal for a new section, is as follows:

6.5.x Other-party Property

 Since a user's experience on a given site might be composed of resources that are assembled from multiple domains, it might be useful for a site to distinguish those domains that are not subject to their own control (i.e., no information might be obtained via the controller property or the same-party property). An origin server MAY send a property named other-party with an array value containing a list of (sub)domain names that the origin server claims to include, to the extent they are referenced by the designated resource, and if all data collected via those references do not share the same data controller as the designated resource. 

 

 A user agent might use the other-party array, when provided, to inform or enable different behavior for references that are claimed to be other-party versus those for which no claim is made or listed under controller or same-party. For example, a user agent might choose to exclude, or perform additional pre-flight verification of, requests to other (sub)domains that have not been claimed as other-party by the referring site. 



Subsequently, I propose an additional line to the Orderly schema reflecting the other-party property.


 array { string; } other-party?;   // (sub)domains


Regards,
Rob

-----Original message-----
From: Matthias Schunter (Intel Corporation)
Sent: Tuesday, April 25 2017, 2:41 pm
To: public-tracking@w3.org (public-tracking@w3.org)
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