Tracking Protection Working Group Teleconference

22 May 2017

Meeting Minutes

<wileys> Here

<schunter> https://‌github.com/‌w3c/‌dnt/‌issues/‌21

<wileys> More important than the proposal is a review of the motivation of the additional TPE elments and their intended use by implementors - across all parties included expected handling by UAs

<wileys> there

<wileys> their

<schunter> A site that registers an exception MUST publish...

<rvaneijk> nice change indeed

<mikeoneill> i will change that after this meeting

<wileys> Well stated David!

<mikeoneill> The TSR is meant to be dynamic, i.e. could be dependant on DNT 0 or 1

<wileys> Machine readable = Tracking Protection LIst

<wileys> Starts as optional until the EU Data Protection Board attempts to mandate it in some fashion

<wileys> Not trying to state it is P3P

<wileys> Happy to answer those questions

<wileys> To be fair this conversation is a bit out of scope of DNT

<dsinger> https://‌github.com/‌w3c/‌dnt/‌issues/‌22

<schunter> Our goal is to simplify EU compliance. More transparency may be a useful part of it.

<wileys> DNT is not the end-all-be-all solution to EU compliance

<schunter> Sure. This is why we only discuss one field ;-)

<wileys> So at some point we need to focus on the goal of the DNT signal itself and not be pulled into rabbit holes for Tracking Protection Lists (otherParty)

<schunter> Concern by shane: Mis-use of otherParties as whitelist for blocking

<rvaneijk> I do NOT see the otherParties property as a quid-pro-quo approach, i.e. blocking when DNT:1 is ignored.

<rvaneijk> This WG's charter was extended with a specific focus on the viability of TPE to address the requirements for managing cookie and tracking consent that satisfies the requirements of EU privacy legislation.

<rvaneijk> The otheParties text proposed is - I believe - an important buidling block for consent. It allows publishers but also, e.g., embedded resources to make representations in a machine readable format.

<rvaneijk> I proposed an optional field. Yahoo! does not have to use the otherParties property, just as there is no obligation to use the sameParty property.

<mikeoneill> ptherParties is site-specific (it relates to the site). Tracking Protection Lists were web-wide as implemented by MS and FF (I beleive)

<rvaneijk> The list Shane is talkig about fits nicely in the sameParty/otherParty array.

<rvaneijk> ... in a (sub)domain format

<Zakim> dsinger, you wanted to ask (a) which way the otherParties array can be wrong (by omission, by inclusion); (b) what statement/promise is being made about these otherParties (to

<wileys> And more importantly - what happens if the list is “wrong”? Does the DNT signal change in someway? Again, the otherParty list appears to have no utility with respect to the DNT signal.

<wileys> What if my Site Specific exception list includes a domain not in the otherParty list? Or the other way around? How is the DNT signal impacted?

<dsinger> so, if present, the otherParties array MUST include all otherParties that might appear (recursively, by inclusion) on the site.

<dsinger> can we see a precise proposed text, please (before a formal CfO)?

<schunter> next week: final text proposals

<schunter> in 2 weeks: objecttions (substantiated)

<wileys> So conflict with the Site Specific exception list, no direct bearing on the DNT signal, and looks/feels/smells very much like a TPL

<schunter> afterwards: chairs discuss and determine consensus

<wileys> We support human readable lists

<wileys> When does the charter run out?

<rvaneijk> wileys, the charter runs until end of the year.

Minutes formatted by Bert Bos's scribe.perl version 2.22 (2017/04/20 17:13:05), a reimplementation of David Booth's scribe.perl. See CVS log.