W3C

- DRAFT -

Tracking Protection Working Group Teleconference

03 Aug 2016

See also: IRC log

Attendees

Present
wseltzer, matthias, Rob, moneill2, npdoty, jeff, dsinger, ChrisPedigo, weiler, Fielding, Vincent, WileyS, walter, CraigSpiezle, aleecia
Regrets
Chair
Matthias
Scribe
wseltzer

Contents


<scribe> scribenick: wseltzer

ChrisPedigo: We're now Digital Content Next

<schunter> User 2 is Rob

Introduction

schunter: Welcome back
... Good you all still exist
... we pushed both specs out, and then nothing happened
... about a month back, Wendy asked "should we recharter?"
... a bit of discussion on the list
... Many browsers have implemented the header
... my sense is that the compliance spec is not widely used
... So, we could leave the specs in CR
... until something happens and then reopen
... Or, we could make the last push over the line now
... I'd like to hear pros and cons in discussion
... The lazy option is to do nothing
... Question 1: are there signs of implementation and use?
... data-gathering

dsinger: other questions: if we discontinue and we get bug reports, what happens
... if we get implementations, how do we move forward?
... and if there's group that does nothing, what's the impact?

schunter: if the group doesn't exist, there may be a forum for bug reports
... if a group does nothing, that's not much use

<dsinger> we should surely have a documented way to file bug reports

dsinger: we should make sure there's a place for bug reports even if we dn't re-charter

<schunter> Decision: if we discontinue the group, then there should be a well-defined way to report and archive bug reports.

<wileys> Agreed - close out existing work but do not extend charter until we have enough implementation experience to move forward on a v1.1

<npdoty> I would suggest in any case we should keep the mailing list not only for bugs but also for gathering implementation reports

moneill2: there are people doing server-side implementation
... big client problem is lack of implemented JS API
... it's in IE, Edge has a bug
... not sure it's anywhere else
... at the moment, TCS refers to exceptions mechanism of JS API

<wileys> What is the percentage of web servers that have implemented DNT v1 at this point? A handful out of millions? 0.000001%?

moneill2: if it's not there, it's a problem

<dsinger> (thinks it would be really useful to hear of sites that need the exception API to function)

moneill2: Also, EFF has a version of the policy
... I'm being apporached by people who want to implement DNT using EFF compliance
... I'm saying they should use W3C's and use compliance proeprty to point to
... Medium.com has a pretty good technical implementation as a publishing platform
... uses out-of-band consent

<schunter> EFF could migrate to the TCS way to publish their policy server side (currently they use their own well-known URL)

<wileys> Medium only uses OOBC - so they’ve only implemented the very basic elements of the standard

moneill2: bits of pieces from implementation, bugs or minor changes to features
... implementation experience
... Same-party array, you need to specify each subdomain. Why not just say .domain?

<wileys> We had suggested a wildcard initially - not sure how that was lost.

schunter: we can keep those queued
... formal question for W3C -- we need a bunch of implementations
... we don't need percentage

<wileys> 1 or 2 is good enough? I thought we needed more???

<jeff> Wendy: Exit criteria are interoperably implemented by multiple (usually 2 or more) independent implementations

<jeff> ... does not refer to percentages

<jeff> ... but we can ask: "is it useful based on scale of implementation and adoption?"

<npdoty> I think most of our goal is to have larger implementation than 2 :) but we can show interoperability through that

schunter: IE does the most client side
... one or two server-side implementations

<wileys> Client-side implementations are only the basic level at this time

schunter: is anyone aware of other uses of compliance?

ChrisPedigo: Re EFF, an ad network is working with EFF in some way; could be interesting to figure out how

schunter: EFF has a proprietary implementation of TCS

<dsinger> (notes that the Charter http://www.w3.org/2011/tracking-protection/charter doesn’t mention exit critera as far as I can see…)

schunter: technically, they don't like our policy, but should be able to use our tech

<wileys> Yahoo’s implementation is compliant (mostly?) with the W3C TCS but we’ve not fully implemented the TPE (similar to clients)

<dsinger> (but Process 2015 documents Implementation experience requirements http://www.w3.org/2015/Process-20150901/#implementation-experience)

moneill2: they don't like our permitted uses

<schunter> ack

<npdoty> dsinger, I think we're referring to the exit criteria for Candidate Recommendations in general

npdoty: I'm meeting with Medium today
... they have an interesting server-side implementation
... we're in the "call for implementation" phase
... if we wanted to go further, we could write an implementation guide

<npdoty> implementation guide, or user documentation

<schunter> ack

<jeff> Wendy: Follow-up on question of bug reports

<jeff> ... Propose that mailing list and wiki continue to serve

<jeff> ... and implementation discussion

<jeff> ... other aegis of Privacy Interest Group

<jeff> ... If we stop TPWG

<jeff> ... On "implementation"

<jeff> ... each feature needs interoperable implementations

<jeff> ... we need to go back to TPE feature by feature

<schunter> ack

<jeff> ... remove things that did not have implementation.

<dsinger> (typically multiple at each end, i.e. multiple clients and multiple servers…)

walter: re implementations, Twitter
... a sizeable service

<npdoty> yeah, it would be nice to know the details of Twitter's implementation experience as well

walter: 2 questions: would it be doable for W3C to re-charter limted to technical spec?
... I think it's achievable for TPE
... How do people feel about the effort required?

schunter: to push this discussion further, other comments?
... finish the implementation discussion, then ask, should we continue TPE, Compliance? recharter?

<wileys> chicken/egg issue on server-side implementations since no client supports the full set of features in the TPE

moneill2: because we don't have JS API, we have problem with caching

<npdoty> could we take that detail to the list?

<schunter> Matthias: there will be some effort required time to maintain and improve

schunter: if we continue, there's substantial time, not just push the buttons

<wileys> Agreed - don’t believe the TCS is needed at this time

schunter: re Compliance spec, I don't see anyone implementing, don't think we need it

dsinger: I don't want to charter a group that doesn't meet; also don't want W3C to shut the door on potential future work

<wileys> David - couldn’t we recharter if interest increases proportionally to the effort to continue?

<wileys> +q

dsinger: it's possible that in the future someone will find them useful because, say, a regulator points to them
... don't want to give false impression that they're being worked on

schunter: My answer, I was ignoring the group for a while; that's not what I'd propose going forward if we reacharter
... it's a group decision to commit time, if we recharter

<dsinger> If we can re-charter if interest picks up, then I’m fine with that, and with that as a message; the specs are in CR, we ask for implementations, and if interest picks and and/or bugs are reported, we’ll re-charter to handle that

schunter: re potential that someone might eventually like it, that's not enough to push to Rec
... if we want to get TCS over the line, we need to to find real implementers

npdoty: I had some similar feelings to David; I don't want us to put effort into just waiting
... on the other hand, if we get bug reports, do we need a rechartering then to fix the bug?
... server-side implementation is more interesting question, and I don't think we've seen a lot
... if we're saying TCS isn't being used, should we point them to EFF's doc?

<schunter> Question: If we do not to the compliance spec, we should say what people can point to.

wileys: I don't think W3C can support EFF's TCS, since the WG didn't support that

<schunter> Shane: We should not; Servers can point to policy document they prefer (since W3C has nothing standardized)

wileys: is it possible to pause without saying the standard isn't going forward
... we're taking time to learn more what's needed
... once we know what's needed, it's not hard to recharter

<schunter> Wiley: Does not support continuing the TCS. Would be OK to continue TPE

wileys: wait to see what external pressures emerge

<npdoty> I'm not suggesting we formally endorse any alternative compliance, I'm just saying, if we aren't going to continue with W3C Tracking Compliance, aren't we suggesting people go elsewhere for compliance policies?

<Zakim> jeff, you wanted to address David's question

jeff: to David's question, if there's something we want to do now, that could be a reason to recharter
... but not keep it in charter just in case we need it
... PING can host discussion in the interim, and then re-charter if we find reason
... I also agree with what Shane said about EFF

<Vincent> Many websites wait for a standard industry to start implementing: https://www.google.fr/?client=firefox-b#q=There+is+currently+no+industry+standard+for+how+companies+should+respond+to+%22do+not+track%22+&gfe_rd=cr

jeff: 's recommendation. A WG could, after discussion, endorse another group's work
... but this isn't a WG right now

schunter: if we were to finish TCS, it would probably take half a year
... recharter

<npdoty> again, I'm not suggesting a formal endorsement jeff, I'm just pointing out that if we don't want to continue with it, we should expect people to look at the only existing alternatives

jeff: in principle, we can write what we want into a charter

schunter: if we recharter with TCS, technically, we can point to EFF's proposal

jeff: look to normative reference guidelines re what a chartered group could say

Vincent: If we don't complete the standards, we're unlikely to see implementation
... no incentive; they use the excuse that htere's currently no industry standard

<schunter> Finishing TPE would encourage further implementation (while not continuing may further reduce adoption)

Vincent: e.g. search for "there is currently no industry standard" and you'll find it in many companies' privacy policies
... if we write the standard, they have to make a decision

<schunter> ack

Vincent: California law says htey have to say whether they respond to DNT

walter: agree with Shane

<jeff> [For Matthias, and anyone else interested - our normative references policy --> https://www.w3.org/2013/09/normative-references.html]

walter: I think we should move TPE forward; not TCS
... GDPR suggests 2-year time-frame for take-up of TPE
... I was thinking refer to EFF as example

<walter> wseltzer: yeah, that would be good

moneill2: there's already activity on TPE
... there can be other compliance documents
... proceed with TPE
... as dsinger said, turn JS into async
... Privacy directive review may point to DNT
... some comments saying it should be obligatory

dsinger: you talked about finishing compliance spec; it's in CR, I'm not aware of anything we should be doing to it
... we should say we're waiting for implementation, implementation report

<npdoty> +1 dsinger, we are waiting on implementation experience

dsinger: if that arrives, we'll consider taking it to Rec
... re TPE, there is work to do

<walter> dsinger: The thing is, people won't submit bug reports, there'll just be competing compliance specs

dsinger: motivation may be low until someone asks for it

<Zakim> dsinger, you wanted to ask what Matthias means by “finish TCS”?

<moneill2> i am up for it

<jeff> Wendy: Hearing more support for TPE than TCS

<jeff> ... original charter said to move to CR in sync

<jeff> ... in a new charter we could ask membership about a single document

<jeff> ... but, what are we telling users if we say

<jeff> ... "here is a header, we are not aware that servers pay attention to it, go implement anyways"

<jeff> ... do we have a compliance story (at all) that motivates continued work on TPE

<jeff> ... ?

aleecia: I've been studying DNT academically

<schunter> Proposed Consensus on TCS: 1. Leave TCS in CR for now (if we later receive substantial implementation, we may pick up again); no rechartering if this is our only activitiy

aleecia: mild uptick on adoption ion 2016
... visibility from California's law
... most saying "DNT is unfinished, so we can't implement"
... there's a perception that we're not finished
... could be valuable for W3C to do press calling for implementations
... help in understanding what phase we're in

<npdoty> we can and should point out to people that we are at a stage where DNT Compliance can be implemented (in contrast to some privacy policy statements)

aleecia: also +1 to npdoty's implementation guide suggestion

<schunter> ============= Discussion on TPE to start =========

aleecia: ots of implementors aren't standards people, don't understand
... so I'd propose do a bit more with TPE to focus on how to go forward without browser implementatoin
... bootstrap problem
... concern that without some type of compliance doc, TPE is rudderless
... we'd need to pull TCS refs from TPE and say what to do in its place
... agree not to endorse EFF version of TCS
... despite EFF having open process, don't think their result would win our group's consensus

<schunter> Aleecia: Simplified support for TPE by non-browser tools (to allow adoption if browsers do not fully support TPE)

aleecia: if there's no W3C DNT Compliance, then EFF becomes Do Not Track, lots of regulatory interest
... support going forward

schunter: Consensus I hear on Compliance, it's in CR, people can implement, no one is eager to move forward on it
... leave it in CR unless we receive reports.
... Re TPE, choice between doing nothing, push for implementations, debug, try to finish
... I think we're 95% there

<npdoty> do we have enough implementations on those features to go ahead with either changes or PR transition?

schunter: does anyone object to continuing
... we have TPE in CR, if we recharter, I'd actively call for implementatoins, few months feedback, look for features to improve, drop, and then push to Rec
... alternative, leave in CR

npdoty: do we have enough implementations already to go ahead?

schunter: formally, we probably have enough'
... but I'd be inclined to call for input

dsinger: you need to ask that question of every feature
... I think the exceptions API is clearly at-risk

schunter: agree

<jeff> Wendy: We HAVE called for implementations

<jeff> ... we can call for such reports at PING without rechartering

<jeff> ... do we have people that are committed to doing the work?

<moneill2> yes

<jeff> ... analyzing the reports, updating the specs

<jeff> ... so that if we ever recharter we would have commitment to getting work done

<jeff> ... otherwise - once we hear that there is implementation experience

schunter: I can chair for the TPE

<jeff> ... we can then reopen the chartering discussion.

schunter: question to David and Roy

Fielding: I'm available
... I'd prefer that we not call for implementation experience until after we've asked browsers informally what they want to do
... no point in talking about current TPE if no one plans to implement JS API
... we could think about cookie-based API instead
... wouldn't need to charter a WG, could experiment on the side

<npdoty> if we're going to design new APIs, I think we should do that in a WG that has IPR protection

Fielding: so I'd say don't call for implementation until we have indication of implementation interest
... informal

schunter: so you'd start with informal discussion

Fielding: just with the browser devs who haven't implemented parts of the protocol we consider significant

<Zakim> dsinger, you wanted to ask that BOTH specs be revised to indicate (a) how to report experience and bugs and (b) link to the list of reported bugs. No matter what else we do.

dsinger: Neither spec indicates how to file a bug, how to find out what bugs have been reported
... should revise CRs to point

<npdoty> I think all specs have a note about where to report experience, with a link to the mailing list

dsinger: I think we'll find browsers are pragmatic, waiting to hear need
... they wont' implement API until htey hear servers need

Fielding: and servers say they wont' implement exceptions until browser do

schunter: EFF has specified Compliance doc, does anyone know if it's adopted?

CraigS: We've been tracking adoption

<npdoty> schunter, the EFF doc isn't a TPE equivalent, which I think is the current topic

CraigS: about 3.5-4% of sites honoring

<schunter> (as discovered by looking at the privacy policy).

CraigS: people reached out to us, wanting to implement, but how, it's not yet done?
... circular references
... 35% of sites doing disclosure of DNT use

<npdoty> just letting people know there is an implementable compliance specification shouldn't be too hard, I hope :)

schunter: should we continue next week

wseltzer: Regrets next week

<npdoty> or could we discuss on the list?

<Vincent> sgtm

wileys: or 2 weeks

<Zakim> jeff, you wanted to ask more about chicken and egg problem

jeff: 2 different kinds of chicken and egg problems
... one possibility, servers and clients really want to get a Rec, but can't justify resources because they don't know the other is doing it

<dsinger> things to consider: (1) edit both specs to encourage implementation and bug report (2) link both specs to reports received (3) extend long enough to think about (a) the chicken-and-egg problem and (b) the async exceptions API problem. (4) ask for a short charter extension while we think (5) convey clearly that we’re waiting for implementation, the ball is not in the W3C court.

jeff: if we're in that situation, bring parties together, find a way
... or, alternatively, neither side, or only one side, has any interest in implementing .In that case, there's nothing we can do
... in the run-up to CR, I had lots of conversations with people exasperated with the process

<Vincent> Chiken and egg is not between client and server, but between us waiting for implemntation and server and clients waiting for a recommendations

jeff: team wasn't pushing hard to recharter, because of impression that people don't really want to implement
... if someone proved us wrong, then we shoudl recharter
... get facts on the table before deciding

schunter: reconvene in 3 week
... I'd like to talk to @@
... whether they're interested in implementing on server side

<Vincent> why 3 weeks?

<walter> That period isn't too good either

<walter> +1

moneill2: I'd go for next week

<Vincent> 10th, 17th or 31st would work for me

moneill2: enough activity to talk

<wileys> 17th or 24th work for me

moneill2: re chicken and egg, it's important to hear about JS API plans

<Vincent> also in favor of next week

schunter: 31

<rvaneijk> 31st fine with me

<wileys> 31st works for me

schunter: next week and 31st

<jeff> 10th or 31st work for me

<wileys> I won’t be able to join with only one week notice - have a standard conflict

<wileys> standing

<moneill2> i am but they dont answer

<walter> Weren't they on the group anyway?

schunter: can people talk with browsers?

Next meetings, August 10 and August 31

[adjourned]

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/08/03 17:07:46 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/formally/formal/
Succeeded: s/wee/week/
Found ScribeNick: wseltzer
Inferring Scribes: wseltzer
Present: wseltzer matthias Rob moneill2 npdoty jeff dsinger ChrisPedigo weiler Fielding Vincent WileyS walter CraigSpiezle aleecia
Found Date: 03 Aug 2016
Guessing minutes URL: http://www.w3.org/2016/08/03-dnt-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]