W3C

– DRAFT –
Tracking Protection Working Group Teleconference

15 May 2017

Meeting Minutes

https://‌github.com/‌w3c/‌dnt/‌issues/‌22

<walter> yes, that's best

Text proposal for otherParties (from Rob):

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 [CUT]

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.

<wileys> I thought we agreed that we have OtherParty from the Site Specific Domain List?

two usages:

1. Information/transparency from a privacy point of view

2. Declaration what third parties are expected to appear on this site

Question: should this constrain a site-wide exception?

<dsinger> ok, so this is for the case of a site-specific exception that’s granted for “*” (all embedded sites), either because the site asked for * or the UA ‘broadened’ the request to *, the UA ‘may’? restrict the exception to the origin site and its other-parties?

<wileys> Has nothing to do with DNT - it’s a tracking preference list

<wileys> tracking protection list

<wileys> With this new perspective of “OtherParty having NOTHING to do with DNT” then we should remove this from the discussion.

IMHO we agreed that all parties that are not on otherParties should receive DNT;1 (if it is declared)

<wileys> This is more clearly another form of Tracking Protection List

Those guys would then be listed in the API for publisher transparency

It is not about blocking. It is about who should receive DNT;1

<wileys> They should recieve whatever the user has selected as their default setting

<dsinger> so, this theory says it’s about a claim of trustworthiness on the part of the site about other-parties, and might result in UAs not visiting (aka blocking) third parties not on the other-parties list; orthogonal to DNT. No relationship to exceptions and DNT.

<wileys> Then what is its value? As a publisher I should be able to provide a list via a link - not a machine reasable list

<wileys> readable

<wileys> Trying to make the list machine readible

<wileys> Revert back to a link and we meet the legal bar

<dsinger> OK, so now Matthias is back to linking it to exceptions. I am confused. We have two completely different theories

<dsinger> what consent?

<wileys> Transparency can be provided by a link - not a machine readable list

<wileys> Machine readable = tracking protection list

Agreement was: otherParties: Field that declares third parties and may be used to constrain a "*" exception.

<wileys> I would avoid the “*” and just list the 3rd parties in my site specific name value pair list

API should allow publisher to retrieve all TPs that appeared that did not receive DNT;0

<wileys> It is not required to provide a machine readable list - a link will suffice

<wileys> Read the email list - Rob would like this to serve as a blocking list

otherParties: 1. transparency: what are the third parties that may potentially appear on the site and track you

<walter> schunter: your sound is breaking up a bit at times

<walter> (this may just be my connection though)

<wileys> Coming through clear for me

2. This may be to used to constrain a site-specific expceiton with the pattern "*"

Whenever a publisher has a site-wide exception and some TPs do not receive DNT;0, then this be discoverable via an API

<dsinger> What you just said is a spec violation on the part of the UA.

<dsinger> We don’t need fields to report violations of the spec.

It seems as if our consensus is falling appart. I will issue a CfO for the next week's call. Any objections?

<dsinger> for a CfO, we need the proposed spec. text (and background)

<dsinger> to be clear, I am not sure we are the impasse that a CfO is supposed to resolve; we seem to be confused about what the proposal is

<dsinger> it may be that given spec. text, we can reach consensus

https://‌github.com/‌w3c/‌dnt/‌issues/‌21

<wileys> I want to reconfirm that invited guests (non-paying members) are not able to participate in the CfO vote

<walter> wileys: which is correct AFAIK

<wileys> Thank you Walter

A Tracking Exception MUST only be granted when the document origin requesting it has a valid Tracking Status Resource at the well-known location, from which information about the domain’s controlling entity(s) and their privacy policy can be ascertained.

A user agent MAY refuse to grant a Tracking Exception for a Site-Specific “target” domain (see Section 7.3.2) which does not have a valid Tracking Status Resource at the well-known location.

<dsinger> Mike’s text has a contradiction: is it MUST or MAY?

<walter> wileys: mind you, in the *vote*

<wileys> Correct - invited guests can contribute to the discussion of course, just not the vote

<wileys> q_

<walter> then we're on the same page

<dsinger> …and, are there any required fields in the TSR? Would an empty TSR satisfy the formal requirement?

<walter> wileys: it may help you in convincing others to participate more that in BXL there's way more attention for the DNT WG than before. NGOs are getting questions about it from MEPs

Clarify: mandatory fields: controller and compliance-url

<dsinger> ok, thanks; MUST applies to the caller, MAY applies to targets; the only question is whether a TSR with just a tracking status is at all useful

<wileys> BXL = BRU?

<walter> wileys: yes

<walter> well, BRU is the IATA-code, for other purposes BXL is typically used as an abbreviation

https://‌github.com/‌w3c/‌dnt/‌issues/‌19

<wileys> Walter - cool - that’s new for me. We usually refer to locations by their airport code in the US and abroad

<dsinger> three possible fixes: remove the permission for UAs to broaden the request; remove the requirement to report the broadening back to the server; introduce a return value to report it.

<dsinger> but if we are going to promises, we should put this information in the promise call-back

https://‌github.com/‌w3c/‌dnt/‌issues/‌26

<wileys> Most sites would likely require a more seriel implementation - meaning a user won’t move forward until the UA provides a signal the exception was recorded as expected

e.g. other-party ==> otherParty

<walter> wileys: it is .be specific abbreviation, or the wider benelux, I should not have used it in an intercontinental context

<wileys> Walter - I like it - BXL is cooler than BRU :-)

<wileys> Walter - generally anything with an “x” in it is cooler :-)

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 [CUT]

<wileys> We’re over - I have to go but want to jump into this conversation next week

Suggestions: (1) David and Roy have an 1:1 to educate David

(2) next week we rediscuss this issue a final time

(3) I will explain the CfO process and rules and we may or may not go for it (depending on the outcome of (2))

Minutes formatted by Bert Bos's scribe.perl version 2.25 (2017/05/19 13:30:32), a reimplementation of David Booth's scribe.perl. See CVS log.

Diagnostics

No scribenick or scribe found. Guessed: schunter