RE: Call for Objections, Issue 22

Shane,

 

I have commented inline.

 

Mike

 

From: Shane Wiley [mailto:wileys@yahoo-inc.com] 
Sent: 13 June 2017 21:26
To: Matthias Schunter (Intel Corporation) <mts-std@schunter.org>; public-tracking@w3.org
Subject: Re: Call for Objections, Issue 22

 

Still unable to reach the CfO page so posting my response here:

 

I continue to recommend we not add "otherParty" at this time as currently scoped, defined, and intended for use.

 

Issue 1:  otherParty doesn't impact the DNT signal in any way.  As we've discussed on the mailing list to meet the requirements for Consent under GDPR options already provided under the TPE cover those needs.  

 

- SameParty Array:  any domains, both 1st and 3rd party, can be accommodated with this feature which is already available.  For example, a 1st party requesting a site-wide exception can list it's 3rd party domains in this list so they receive DNT:0.  ANY party not in this array will receive the user's default DNT value.  Assuming that's DNT:1 then domains not listed in the SameParty array during a User Granted Exception will receive DNT:0.  

 

same-party does not determine what DNT header values get sent to anyone. Only the general preference, the API, or the UAs own UI can do that.

 

The otherParty doesn't change or assist in the DNT signal a party receives - in any way.  It is proposed as a list of domains that are not under contract with the 1st party but because the 1st party is aware of them it would like to list them for transparency purposes - but not changing the default DNT signal they receive.  It's this very specific disconnect with DNT that suggests this is not an appropriate addition to the DNT standard.

 

It has exactly the same relationship to the DNT header as the other TSR properties. They do not change what DNT gets sent, though they might have different values depending on the DNT header the server receives in the request, because the TSR can be dynamically generated according to request input.

 

- TSRO:  The tracking status response object already provides the opportunity to link to a list of 3rd parties in human readable form.  The desire to provide a machine readable list is addressed in Issue 2.

 

The TSR points to a human readable policy page, which can contain anything. There is no way in the existing TSR to list domains other than those that the site (browsing context) lists as its own or as it service providers in the same-party array. That is why you need an other-party array.

 

Issue 2: otherParty is a Tracking Protection White List.  As discussed in the email list the desire for a machine readable list is specifically to allow the web browser to take some action with respect to that list - blocking was mentioned as one outcome of any domain that is not found in the sameParty or otherParty arrays.  The WG spent considerable time discussing the pros/cons of Tracking Protection Lists and becoming involved in domain blocking.  This resulted in the group unanimously agreeing to drop the pursuit of this path.  Again, to be as clear and plain as possible, otherParty is intended to be a blocking list - not a transparency tool - in my opinion based on the need for machine readability and the email discussion on the intention of browser intervention based on domains listed.

I have told you my opinion on this.

 

I don't want to discourage this pursuit more broadly and support the desire to add privacy tools that provide greater transparency to users over what already exists today between browser tools, controls, and add-ons available in the market.  Attempting to use DNT to add none DNT relevant elements in not the correct path to arrive there IMHO.  I would recommend a new working group be formed to discuss broader transparency tools that can live outside of the use of DNT and in that context a group can more thoroughly look at all possible elements of transparency that could become available in both human and machine readable form (P3P v2?).

 

- Shane

 

Shane Wiley
VP, Privacy
Yahoo

 

  _____  

From: Matthias Schunter (Intel Corporation) <mts-std@schunter.org <mailto:mts-std@schunter.org> >
To: public-tracking@w3.org <mailto:public-tracking@w3.org>  
Sent: Monday, June 5, 2017 9:49 AM
Subject: Re: Call for Objections, Issue 22

 

Dear TPWG,

for those who do not remember what a call for objection was about, here
is some guidance.

The goal is to find a consensus that people "can live with". The
procedure is that anyone can provide "substantiated objections" to any
of the (two) alternatives. The chairs will analyze the inputs and will
try to identify the alternative with "least substantiated objections".

Substantiated means that you should provide evidence/data/sound
arguments if possible (preferences/opinions usually have less weight).

Objections means that you should explain why your industry / company /
stakeholders cannot live with this option.

I hope this guidance helps adding data. If you have further questions,
do not hesitate to ask...


Regards,
matthias


On 02.06.2017 21:03, Wendy Seltzer wrote:
> Hi TPWG,
> 
> At Matthias's request, in Bert's absence, I've opened a Call for
> Objections on the "Other Party property," a proposal to close github
> Issue 22[1].
> 
>    https://www.w3.org/2002/09/wbs/49311/Issue22/
> 
> Responses to the Call for Objections are requested by Monday, June 12.
> 
> Thanks,
> --Wendy
> 
> 
> [1] https://github.com/w3c/dnt/issues/22
>