<JoeHallCDT1> in the room physically are fwagner, schunter, Mike O'Neill, dsinger, and JoeHallCDT

<rvaneijk> -me I was surpriced by Thomson Reuters.

<JoeHallCDT1> scribenick: JoeHallCDT1

schunter: DT and RT would be interested to try to join an implementation study
... we are discussing a way forward, hinges on a case study
... either regulators are interested and find it compelling or not
... can technicians ever make regulators happy?

rvaneijk: may be difficult to get the certification from Art. 29
... could present the imp to German DPA
... timeframe is potentially crucial
... in May 2018 there will be a new data protection board constituted
... that board will address vague or unclear parts of the regulation and make decisions
... as to whether or not a given thing is compliant or not
... if the question is how to make regulators interact with this (?)
... it would be to present data flow examples to DPAs
... they are all connected to consent in GDPR
... TCS resource is the first important part to show regulators

fwagner: would be good to announce in January that we are doing this and then present results somewhere

<rvaneijk> http://cookiesv2.publiekeomroep.nl/data/sites/nos.nl/cookielist/#tabs-recommendations

schunter: we want to decide on a timeline for rechartering purposes
... and then we can have a better idea about moving on to PR

<schunter> •Debug TPE –Mark some features at risk / describe our concerns –Any other debugging •Case Study  / Implementation Study –Demonstrate GPDR compliance using TPE –Obtain more confidence/feedback for TPE •Potential revisions of TPE –Are features missing? –Are features not needed? –Can we futher reduce complexity? •Move towards full recommendations

schunter: after the case study with TPE, we can move to PR with both of them
... once the study is done, there's no point in not publishing it

wseltzer: on the compliance spec, are we recommending people implement that

mikeoneill_: aleecia said that from the US perspective it would good to have TCS in there

dsinger: it's a good thing as it is not a complete spec without that

schunter: one question: if you want to go for GDPR as the main use case
... are there modifications to the spec we need to do?
... that would mean we'd need to go back to LC?

wseltzer: LC no longer exists, would go immediately to a new CR

schunter: ah, so now it's easier to update it? (yes)

mikeoneill_: that means we could bind in certain changes and things we've found in imp

fwagner: what does this mean for the future?
... if we get a "go ahead" from regulators
... and we need a compliance spec to refer to
... does this mean the existing TCS needs to modified for GDPR?

schunter: yeah, want to do this out of w3c

<rvaneijk> In EU you only need TPE.

I think they're saying TPE references TCS so it's needed

schunter: we can publish w3c notes for certain purposes
... do not want to start standardizing another TCS

fwagner: thinking of potential problems for companies if they can't say they're compliant with a specific standard if one doesn't exist

<rvaneijk> agree with schunter to not start standardizing another TCS

<schunter> For dt it is important that TCS is not requirement.

<JoeHallCDT> scribenick: JoeHallCDT

cargill: so we're ditching TCS?

schunter: no, it seems important for the US folks
... but it's not useful for EU context

cargill: TCS is one example of a particular compliance spec

dsinger: we can require that you link to one TCS, but that is an example, so point to what you are compliant with

schunter: yes, up to the company to pick a TCS

cargill: is that acceptable to regulators?
... Samsung: self-regulated, self-compliant
... and it quite literally blew up
... do we want to make a point that these are third-party compliance spec?

mikeoneill_: we want the regulators to come to an agreement about (?)

schunter: the consent mechanism is particularly important, but the compliance spec need not be the w3c one

fwagner: need a description for how you interpret the technical mechanisms and flow

cargill: as long as there's not a problem with using the TPE only

schunter: you can do TPE and not point to a compliance spec but then it's unclear if there is any meaning behind the signaling
... early adopters will put a URL to their compliance spec

<schunter> (correct: tracking / cookie section of their privacy policy)

mikeoneill_: Article 12 of the GDPR has a requirement for machine-readability and that could be a hook for compliance spec

schunter: need to submit a new charter by the end of the year
... need to plan a timeline with the group
... draft and agree on new charter
... recharter at the end of the year
... one question: should we go through the TPE line-by-line and discuss at-risk, etc.

mikeoneill_: G should be at risk… Shane may not like that

<dsinger> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#TSV-G

<rvaneijk> Agree with mikeoneill_ url in TSR points to priv policy/termsandservices. This is part of a multi layered approach for the information requirement.

mikeoneill_: but the gateway thing doesn't make sense for a party to pass on the TCS for another party

dsinger: let's do it!!!!!!!!!!
... exception calls should be async promises
... the web-wide exception is exactly cookies so why do it?

schunter: we had discussed this as having more transparency for the user

mikeoneill_: unless you specify the name of the cookie, hard to tell what it's for

schunter: storing a cookie in the web-wide API is more transparent

dsinger: it doesn't change behavior of the UA

schunter: if I get a DNT:0 header in a FB widget somewhere that will be a DNT:1 (?)

<vincent_> User may check in their browser to who they gave a web wide excpetion, it's harder to check cookies

<vincent_> how would you know which cookie grant a "web-wide" consent

<rvaneijk> Agree with vincent_ transparency for exceptions is key. Also ability to revoke exceptions.

dsinger: someone claiming a web-wide exception will track you

mikeoneill_: there's also the caching problem… can't vary on the cookie header
... why you need to have the DNT exception API

vincent_: better to have web-wide exception in DNT as you can look in settings and better map those resources to who claims a web-wide

schunter: cookies are considered browsing data, so that will be cleared
... if people erase cookies, our stuff will be zapped too

vincent_: I may want to clear cookies because I don't want to be tracked by 3rd parties I don't know
... and you'll get the pop-up to give consent
... you may not want to give consent again to all the sites you are visiting

mikeoneill_: don't want to stomp on privacy preferences when you clear

schunter: other features at risk?
... exception API
... it's at-risk of a redesign in general. can't see that happening

<vincent_> I think the exception API is key to grant consent

dsinger: would I recommend a preference that sent DNT:0 to everyone?
... not convinced a redesign there that is possible

mikeoneill_: G seems essentially useless
... perhaps if we get the ad-tech people back to work on this it could work

<rvaneijk> G had to do with transitivity as well..

vincent_: the G was for sending signal to multiple parties
... there was a discssion about the status of the gateway… was that a processor?

mikeoneill_: the must forward status to other parties doesn't work

schunter: if an ad exchange is doing an auction, it needs to communicate a tracking status to others

dsinger: this only depends on the site-wide tracking status… "Hey, I'm a gateway, so I sent this to others"

mikeoneill_: not convinced that there is anyway to do this

dsigner: this is all redirect, proxying

mikeoneill_: but this is data proxying, cookie values, etc.

<mikeoneill_> https://trackingprotection.github.io/Implementation/DNTBugs/

<fwagner> CU Rob, take car !

hadleybeeman: https://www.w3.org/2016/09/21-dnt-minutes.html

<dsinger> Comments on the TPE CR:

<dsinger> 1. The fingerprinting section should be made top-level, called “security and privacy considerations” and probably expanded

<JoeHallCDT1> talking about terminology

<JoeHallCDT1> 2. we need some folks like rvaneijk and/or vincent to go through the spec and look for obvious problems related to EU

<JoeHallCDT1> i.e, GDPR

3. look at mikeoniell's comments about HTTP-EQUIV for consideration into the TPE spec

https://trackingprotection.github.io/Implementation/DNTBugs/

<dsinger> I think if we remove DNT-extensions, we’d still want the parsing rules to allow for them, so it’s barely a change to the spec. to leave the parsing rules alone and simply change the text to say it’s for possible future use.

4. change the DNT extensions text a bit, to emphasize despite no current use cases, we want to future-proof

5. in 5.1 need to modify text below

<dsinger> “A user agent must not send a tracking preference expression if a tracking preference is not enabled” needs “, or an applicable exception has been recorded.”

<dsinger> whoops, “, unless an exception has been recorded that applies to that site.”

<dsinger> and again in 5.2 “A user agent must not generate a DNT header field if the user's tracking preference is not enabled.

<dsinger> “

<dsinger> maybe we should re-define “enabled”

to be generally enabled or enabled for a specific site

<dsinger> 5.3 the IDL has “section 5.2 DNT header…” in the middle of it!

6. we'll need to normalize the language and potential responses to match language and interaction in the GDPR (e.g., necessary uses)

heh

freaking Zakim

<dsinger> “In addition, responses to the JavaScript API indicated should be consistent with this user preference (see below).” seems to be free-floating and not “in addition” to the previous text

<dsinger> The explicit-target list in the exceptions is very questionable, to my mind. The UA can broaden it to site-wide, so a site can’t trust it will be respected.

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/terminolog/terminology/
Found ScribeNick: JoeHallCDT1
Found ScribeNick: JoeHallCDT
Inferring Scribes: JoeHallCDT1, JoeHallCDT
Scribes: JoeHallCDT1, JoeHallCDT
ScribeNicks: JoeHallCDT1, JoeHallCDT

WARNING: No "Topic:" lines found.


WARNING: No "Present: ... " found!
Possibly Present: JoeHallCDT JoeHallCDT1 WalterTamboer_ cargill dan dnt dsigner dsinger fwagner hadleybeeman https jeff joined left mikeoneill_ rvaneijk schunter scribenick vincent_ wseltzer
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

Guessing minutes URL: http://www.w3.org/2016/09/22-dnt-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)