<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.)[End of scribe.perl diagnostic output]