Re: Issue-22, possible other direction

Mike and Rob,
The original Tracking Protection List proposal had both White List and Black List components.  Your proposed "otherParty" is simply the White List approach of a Tracking Protection List.  While I find the concept of Tracking Protection Lists interesting from a general privacy perspective, our Working Group decided long ago to abandon this approach and to more specifically apply our energy on the DNT signal itself.  As the machine-readable "otherParty" list doesn't impact the DNT signal itself I'd suggest it is out of scope for this working group.  
You can of course submit a suggestion, much like Microsoft did many years ago, to start another Working Group focused on TPLs to introduce these concepts.  This Working Group decided to abandon pursuit of those approaches long ago and trying to introduce a TPL white list concept now for automated processing by the UA seems to go directly against that agreement.
- Shane Shane Wiley
VP, Privacy
Yahoo

      From: Mike O'Neill <michael.oneill@baycloud.com>
 To: singer@apple.com; 'Rob van Eijk' <rob@blaeu.com> 
Cc: 'Shane Wiley' <wileys@yahoo-inc.com>; 'Matthias Schunter (Intel Corporation)' <mts-std@schunter.org>; public-tracking@w3.org
 Sent: Friday, May 19, 2017 11:53 AM
 Subject: RE: Issue-22, possible other direction
   
David,

What this is for is to offer information to be read, presented in standardised and palatable form, and optionally acted upon by software systems acting for or in the interest of users, for example user agents, extensions to user agents, regulatory scanners etc.

It is meant to convey a list of domains  of subresources that the site is designed to host, or that the site controller is aware may appear. If the array is there and a domain appears that is not on this list or the same-party list, then these software systems can take appropriate action. The obvious case that comes to mind is malware detection, but Rob has also pointed out a use case for online advertising.

The information content is therefore what is *not* on the list, and if the list exists. It is nothing like the Tracking Protection lists that Microsoft introduced years ago, the similar system that Mozilla introduced last year for Firefox,  the analogous content blocking capability that Safari provided 2 years ago or the host of content blocking extensions. It is optional, and whether it is there is determined by the top-level site. 

The same-party (or sameParties) array is similar, but for domains that are either managed by the data controller(s) or their data processors. Same-party also leaves user agents etc. the option to act on it (and the TPE explicitly mentions the possibility of exclusion).

The otherParties lets sites expand this list of domains to those that it does not control, but expects that they may be present. 

I submit this does absolutely increase the ability of user agents to inform users of what is happening on a page, and allows sites to enable user agents to safeguard users interests in a systematic way.

There may be less domains present than that on the list, but the same could be said of sameParties. Data processors may be present on some pages and not on others. Similarly for otherParties, a social networking button could only be present on a subset of pages.

If domains appear that are not on the list then then this is either a bug (from the point of view of the site), or an illicit appearance that could be dealt with. If sites expect and want arbitrary domains to appear they do not have to supply an otherParties property.

Mike
 


-----Original Message-----
From: singer@apple.com [mailto:singer@apple.com] 
Sent: 19 May 2017 17:39
To: Rob van Eijk <rob@blaeu.com>
Cc: Shane Wiley <wileys@yahoo-inc.com>; Matthias Schunter (Intel Corporation) <mts-std@schunter.org>; public-tracking@w3.org
Subject: Re: Issue-22, possible other direction

Do we have proposed spec. text?  

Rob, I am still concerned that the ‘transparency’ may be a myth if I am right and the array can be wrong:

a) by omission; the first party site may pull in sites not mentioned in the otherParty array (quite likely, full coverage may be very hard to achieve);
b) by inclusion: the array might mention sites that are not, in fact, pulled in on a given visit (quite likely, as what other sites are pulled in depends on a host of factors)

If these are both true, then the array could be a complete myth and still conformant. In that case, what use is it to anyone?

> On May 18, 2017, at 13:02 , Rob van Eijk <rob@blaeu.com> wrote:
> 
> Hi Shane,
> 
> Just trying to find a middle ground here. I believe there is a win-win for publishers, companies with embedded resources, and privacy advocates since the overarching problems are actually not that different. If you want to push this to call for objections, fine. I am open to exploring possible other directions a bit further, but like I said, it's up to you.
> 
> I still disagree with the last sentence. Having an otherParties (sub)domain list improves - in my opinion - the standard in comparison with existing fields and paths to transparency. People are not going to read lists of embedded parrties form a url. Instead, I believe people would want to trust their browser being a proxy for them. The otherParties does IMHO not break or create confusion with other parts of the existing standard if defined clearly. I proposed an optional property (MAY) in the well-known resource. The aim is to provide an informational building block for companies who what to be specific about the resources they embed. The information can be read pre-flight from the well-known location.
> 
> Rob
> ———
> PGP id: CC4F3863 [public key]
> PGP fingerprint: 1D00 A9FD 7CCB A5A5 850E 2149 BEA0 20B7 CC4F 3863
> 
> Social media: @rvaneijk, github, linkedin, ssrn, stackoverflow
> ———
> 
> -----Original message-----
> From: Shane Wiley
> Sent: Thursday, May 18 2017, 9:19 pm
> To: Rob van Eijk; Matthias Schunter (Intel Corporation); public-tracking@w3.org
> Subject: Re: Issue-22, possible other direction
> 
> Rob,
> 
> otherParty is not a good replacement for Ads.txt for the following reasons:
> 
> - Carries more information that is ad industry specific
> - List is limited to only ad inventory partners - doesn't list other 3rd parties on the page
> 
> This is a publisher working directly with the ad ecosystem to declare those that should be allowed to participate in a bid prior to it taking place and is specifically made available for the ad call event.
> 
> As your stated purpose of otherParties is purely for consumer transparency (not automated blocking) it doesn't require the same level of detail, can include many other 3rd parties that are not specific to ad serving (such as analytics, video players, widgets, etc.), and doesn't need to be machine readable as a human is the intended recipient for consent consideration.
> 
> - Shane
> 
> Shane Wiley
> VP, Privacy
> Yahoo
> 
> 
> From: Rob van Eijk <rob@blaeu.com>
> To: Matthias Schunter (Intel Corporation) <mts-std@schunter.org>; "public-tracking@w3.org" <public-tracking@w3.org> 
> Sent: Thursday, May 18, 2017 11:52 AM
> Subject: RE: Issue-22, possible other direction
> 
> Hi Shane, David,
> 
> My proposal is in fact not far from the machine readable ads.txt file proposed by the IAB Tech Lab OpenRTB Working Group. (https://iabtechlab.com/ads-txt/).The otherParties property could eliminate the need fot the ads.txt file. We could make the content of the otherParties property useful such that it is fit for purpose for specific consent as well as  minimizing data leakage that will help against domain spoofing and other types of ad fraud/malvertising. Please let me know if we should explore this further.
> 
> Rob
> ———
> PGP id: CC4F3863 [public key]
> PGP fingerprint: 1D00 A9FD 7CCB A5A5 850E 2149 BEA0 20B7 CC4F 3863
> 
> Social media: @rvaneijk, github, linkedin, ssrn, stackoverflow
> ———
> 
> -----Original message-----
> From: Matthias Schunter (Intel Corporation)
> Sent: Thursday, May 18 2017, 6:32 pm
> To: public-tracking@w3.org
> Subject: Re: Issue-22, possible other direction
> 
> Hi Shane,
> 
> we can use this as your text proposal (i.e. only the field syntax is
> changed from array to URL). If you  want to propose something else, feel
> free to do so ASAP.
> 
> Thanks a lot!
> 
> matthias
> 
> 
> On 15.05.2017 23:09, Shane Wiley wrote:
>> Rob,
>> 
>> If a data controller were to provide a link to a list of their 3rd
>> parties in the TSR or to a user more directly during their consent
>> dialogue, would that meet legal obligations?  
>> 
>> otherParty: www.companyxyz.com/3rdparties/list.html
>> <http://www.companyxyz.com/3rdparties/list.html>;
>> 
>> Why does this need to be machine readable if we're taking blocking off
>> the table?  Additionally, since we already allow publishers to only
>> request site specific exceptions for specific 3rd party domains, why is
>> this additional list needed?  We already appear to have all the utility
>> needed to support ad exchange scenarios such that publishers can request
>> consent for only those 3rd party domains they have knowledge of and a
>> contract with - so what does this add?
>> 
>> If these are true:
>> 
>>  - the Data Controller is responsible for the interaction between
>> themselves and the user with respect to consent,
>>  - consent can be obtained by providing a list of specific third
>> parties in human readable form to a user as long as the scope is
>> specific and informed,
>>  - the current standard allows exceptions (consent) to only be
>> provided for a specific list of third parties (wildcards need not be used),
>>  - AND, as a working group we're not attempting to backdoor tracking
>> protection lists for domain blocking
>> 
>> ...I'm not seeing the "transparency" value of otherParty.
>> 
>> - Shane
>> 
>> Shane Wiley
>> VP, Privacy
>> Yahoo
>> 
>> 
>> ------------------------------------------------------------------------
>> *From:* Rob van Eijk <rob@blaeu.com>
>> *To:* "public-tracking@w3.org (public-tracking@w3.org)"
>> <public-tracking@w3.org>
>> *Sent:* Monday, May 15, 2017 12:24 PM
>> *Subject:* FW: Issue-22, possible other direction
>> 
>> FW: Issue-22, possible other direction
>> ... including the lsit
>> 
>>        -----Original message-----
>>        *From:* Rob van Eijk
>>        *Sent:* Monday, May 15 2017, 9:08 pm
>>        *To:* David Singer; singer@apple.com; Shane Wiley
>>        *Cc:* Matthias Schunter (Intel Corporation); Roy T. Fielding
>>        *Subject:* RE: Issue-22, possible other direction
>> 
>>        Hi,
>> 
>>        I think it may be helpful to go back to the initial consensus
>>        [1]. I am not a proponent of an API component in this
>>        discussion. I would be happy with a simple, optional (MAY)
>>        otherParties property in the TSR that complements the sameParty
>>        property. I believe the otherParties property is beneficial for
>>        different types of site owners, ranging from non-tracking sites
>>        to RTB-driven sites.
>> 
>>        I think we can keep the TPE clean and simple. The aim of the
>>        otherParties property is (optional) transparency.
>> 
>>        [1]
>>        https://lists.w3.org/Archives/Public/public-tracking/2017May/0003.html
>> 
>>        Rob
>>        ———
>>        PGP id: CC4F3863 [public key
>>        <https://sks-keyservers.net/pks/lookup?op=get&search=0xBEA020B7CC4F3863>;]
>>        PGP fingerprint: 1D00 A9FD 7CCB A5A5 850E 2149 BEA0 20B7 CC4F 3863
>> 
>>        Social media: @rvaneijk <https://twitter.com/rvaneijk>;, github
>>        <https://github.com/rvaneijk>;,
>>        <https://github.com/rvaneijk>linkedin
>>        <https://nl.linkedin.com/in/rvaneijk88>;,
>>        <https://nl.linkedin.com/in/rvaneijk88>ssrn
>>        <https://papers.ssrn.com/sol3/cf_dev/AbsByAuth.cfm?per_id=1605225>;,
>>        <https://papers.ssrn.com/sol3/cf_dev/AbsByAuth.cfm?per_id=1605225>stackoverflow
>>        <http://stackoverflow.com/users/4725192/rvaneijk?tab=profile>;
>>        ———
>> 
>> 
>> 
> 
> 
> 

Dave Singer

singer@mac.com



David Singer
Manager, Software Standards, Apple Inc.