17:02:02 RRSAgent has joined #dnt 17:02:02 logging to http://www.w3.org/2017/02/13-dnt-irc 17:02:04 RRSAgent, make logs world 17:02:04 Zakim has joined #dnt 17:02:06 schunter has joined #dnt 17:02:06 Zakim, this will be TRACK 17:02:06 ok, trackbot 17:02:07 Meeting: Tracking Protection Working Group Teleconference 17:02:07 Date: 13 February 2017 17:02:13 present+ 17:02:32 present+ moneill2, Bert 17:02:49 wileys has joined #dnt 17:04:35 thanks, Shane! 17:04:42 present+ aleecia, wileys, alantoner, fielding 17:04:42 np 17:04:50 I always wonder the same thing 17:05:00 while we’re waiting, do we have a scribe? 17:06:13 present+ schunter 17:06:24 dsinger has joined #dnt 17:06:44 1 Goals / Procedures 17:06:49 vincent_ has joined #dnt 17:07:03 2. Should we allow transmission of TK headers within http-equiv. 17:07:12 3. Implementation/Validation Strategy 17:07:52 scribenick: npdoty 17:08:02 Topic: Goals / Procedures 17:08:20 schunter: sent email recommending that we try to minimize changes, based on what's necessary for implementers 17:08:30 q+ 17:08:36 5. Other issues from our tracker: 17:08:39 moneill2: agree, concentrate on getting something to Recommendation 17:09:07 ... issue (with site exceptions) that will come up in EU compliance 17:09:07 nick: could you sribe? 17:09:25 (thanks a lot for being proactive! I thought so. 17:09:32 ack aleecia 17:09:32 ack alee 17:10:01 aleecia: repeat from email; agree with approach; can capture issues even if not all changed, agree with goal of getting this done 17:10:31 (suggested time boxing issues and getting to what we can before a deadline, holding off on non-critical issues until the end) 17:10:46 wileys has joined #dnt 17:10:51 +q 17:11:02 schunter: if we have well-documented issue from someone in the group, should consider it. otherwise can wait until implementation experience 17:11:07 -q 17:11:39 schunter: agreement to stay on time, focus on the essential, can capture the list of issues for later 17:12:17 schunter: using github, can add labels/milestones to issues 17:12:28 vincent__ has joined #dnt 17:12:39 ... have started marking them per milestone based on the status of the issue 17:12:57 vincent___ has joined #dnt 17:14:39 npdoty: usually labels for this purpose rather than milestones 17:14:43 Topic: http-equiv 17:14:55 https://github.com/w3c/dnt/issues/10 17:15:30 schunter: we require participation from the server owner, so /.well-known/dnt is server-wide 17:15:51 schunter: site can send Tk headers to point to different versions of a tracking status resource 17:15:58 q+ 17:15:59 ... could the site owner put that in http-equiv 17:16:22 ... pros: it could be convenient, simpler for the site owner 17:16:59 Strong “NO” from a publisher who actually owns a publishing platform and is concerned that low tech skilled users will not understand the complexity of overriding the core domain’s DNT position by posting their own. 17:17:02 ... cons: there could be ambiguities, is tracking a non-content property? 17:17:46 fielding: the primary response is the well-known resource, so the site owner / server still has to set that up 17:17:53 ... the Tk header could give a resource specific response 17:18:12 My concern is that a platform will report on behalf of one of their publishers, and get it wrong. 17:18:23 Since that’s what happened on P3P 17:18:50 ... could be easier to add as http-equiv, but if the site has inconsistent tracking policy, the server would have to parse/change HTML content 17:18:51 …so what can we do to resolve that concern? I am not wed to any particular approach, just to solving the problem. 17:19:01 ... tradeoffs 17:19:28 ... for me, it seems like I can control header fields just as easily 17:19:50 ... if we allow servers that flexibility, then the client has to handle that flexibility 17:19:59 We could put a MUST requirement on platforms, but I’m hesitent there. 17:20:14 ... don't see the advantage in clients having to read the HTML, or later address in JavaScript 17:20:40 If a publishing platform allows its publishers to post 3rd party tracking tech then they will either have to a) disallow their publishers from supporting DNT or b) build a configuration option for publishers to implement their desired position on DNT. Attempting to allow publishers to state their DNT stance outside of the publishing platfrom will cause confusion and will most likely just be wrong - meaning they are lying to users. 17:20:58 ... can understand the interest, but don't see the value to us 17:20:58 it’s that last part that captures my conern! 17:21:29 schunter: issue for mike was hosted site where the host doesn't provide a lot of functionality 17:21:30 If publishers feel this is critical they can select a publishing platform that supports DNT configuration for their posts. 17:21:38 One option is to add text calling this out in the spec, with a SHOULD on a UI as you described. 17:22:02 Well, no: if all publishers are basically lazy, there’s no choice and no incentive for any of them to change. 17:22:04 moneill2: for example, as a first party site with very basic publishing tool, might want to declare that consent has been received, using Tk: C 17:22:07 DNT is completely optional - should not be a SHOULD. Publishers can select the platform they feel best meets their needs. 17:22:12 “The market will solve it” doesn’t work for me. 17:22:24 Then we’re at MUST. 17:22:27 Aleecia - unfortunately that’s how the real world works 17:22:46 Because writing a spec where we know platforms will wind up effectively lying to users sounds like poor design, no? 17:22:59 q+ 17:23:07 ... if for some reason you can't put the header there (loads of people, including companies, don't know how to do that on their sites) 17:23:25 q+ to ask whether we need to decide this in spec 17:23:32 The platform would not be lying if we allow http-equiv and publishers attempt to overwrite the platforms position it is them that are lying 17:23:47 I think only the publisher has the motivation to tell the truth here. Authors don't know, so they will sell sugar. 17:23:49 http-equiv is a bad idea 17:23:51 moneill2: how are third-party advertisers going to gain consent? 17:23:59 Agree with Roy!!! 17:24:10 i’m surprised you’d want platforms to take on liability for publishers on their platform. sounds very european :-) 17:24:42 ... would prefer well-known named cookie 17:24:51 Its a mix of liability based on what features your directly provide as the platform. If publishers go outside of their guardrails the liability is on them. 17:25:35 As a design approach, I’m good with platforms report what they do and their publishers report what they do, and each is responsible for what they actually know about. 17:25:44 ... dynamic tracking status resources -- is it possible to do a preflight on embedded third party resources? 17:25:44 That’s what we’re doing with multiple parties in other contexts. 17:26:30 From the persepctive of use cases: 17:26:32 fielding: wouldn't check preflights because of performance or other reasons? 17:27:25 ... preflight policies would be set in advance and be done in the fetch library 17:27:50 ... preflight not required 17:27:54 Platform collects & uses for de-ideintified analytics, security; publisher on platform does same but does not retain for security. There should be some way to convey this to users. 17:28:36 moneill2: could be dynamic based on a cookie, but first-party sites aren't likely to need that dynamism 17:28:43 In particular, a publisher that collects & uses more data than the platform REALLY ought to have a way to convey that, or else the publisher claims something untrue. 17:29:26 Building a system that’s likely to report incorrect results — as Shane puts it, lying to users — is a failing on our part, especially when it’s foreseeable 17:29:27 moneill2: if we didn't allow http-equiv, would make it more difficult 17:29:36 It is actually VASTLY easier for all sites that do not track whatsoever. 17:29:43 (I didn't know w3.org returned Tk 1, but will investigate.) 17:30:04 They should either a) use a platform that coordinates DNT responses with them or b) don’t support DNT or c) invest a bit of money and build their own website 17:30:13 schunter: there are other fields that could be in http-equiv -- but is that happening automatically? 17:30:30 I’m focused on what the platform should do. 17:30:43 fielding: http-equiv goes back to 1993, with the idea that servers would extract it and turn it into headers on the server-side 17:30:56 As you point out, the platform can simply not offer DNT. Or, they can do something where they’re not lying. Seems reasonable. 17:31:01 ... but implementations didn't do that, so it's just delivered to the client and defined by an HTTP spec 17:31:52 vincent_ has joined #dnt 17:32:05 Another way the platform could handle things is to tell their publishers “here is what we do for DNT and you must match it,” which is a rather less technical way we get things to work, and that would be ok by me. 17:32:09 fielding: here the primary role is to provide the tracking response before we get the content back, and sending http-equiv in content doesn't match that tpwg design 17:32:18 Limiting on the publishers. But at least reality matches the DNT signal. 17:32:34 ... most sites aren't tracking, and a site-wide resource will be easier 17:33:11 q? 17:33:18 ack mon 17:33:27 ack aleecia 17:34:18 aleecia: use case that might be relevant: don't want to replicate p3p situation where a platform reports on behalf of all of its publishers, which actually isn't accurate for all of those publishers 17:34:38 If a publishing platform is falsing stating a position for its publishers that’s on them - they either need to add configuration or contracts that prohibit activities that are against their DNT response. 17:34:47 +q 17:34:49 ... whatever the platform is reporting, there has to be some way to distinguish the publishers on that platform 17:35:31 schunter: this use case is meant to be addressed by the status-id that distinguishes different tracking status resources 17:35:59 aleecia: +1. what do we put in the spec to make sure that that happens? do we just need to explain? 17:36:11 To be clear, I don't mind adding a defined link relation that says its own thing, such as an override of "my privacy policies" 17:36:15 q? 17:36:28 q+ 17:36:39 moneill2: e.g. P3P pasting of policyref headers? 17:37:23 aleecia: publisher reporting compact policies for p3p without realizing because it was platform-wide 17:37:26 TODO: Double check spec for clarity 17:38:21 schunter: the goal is not to mitigate against malicious misrepresentation, but to help publishers/platforms not make policy statements for other people 17:38:26 P3P - today this won’t be an issue as silence is not punished. If we go to the P3P / IE world of punishing silence then we could get back to the world of false representation. 17:38:49 vincent__ has joined #dnt 17:39:02 schunter: can you look at TPE for possible improved text? 17:39:21 action for aleecia to review text 17:39:21 Error finding 'for'. You can review and register nicknames at . 17:40:14 npdoty: do we have to say anything? 17:42:04 Q? 17:42:14 ack npdoty 17:42:14 npdoty, you wanted to ask whether we need to decide this in spec 17:42:32 ... client parsing of it is optional already, if servers think it's easy and clients do it, then what do we care? 17:42:51 fielding: don't want to make it so that it could be in lots of different places, where clients end up looking inconsistently 17:43:17 header / wkl should always be the default 17:43:18 ... if you want to communicate the whole status, could just include the full tsr json in the HTML 17:43:33 hi Shane, today DNT is mostly a transparency tool (without plugins / in accordance with CA AB 370.) So getting the information right is a major part of DNT. If you want to go back to a market choice framing (sigh) then you’re giving users the ability to choose different content publishers. 17:44:20 Pubhlishers already have the ability to choose different platforms - this changes nothing 17:44:30 that’s not what i was saying 17:44:32 ack wil 17:44:35 schunter: could a mischievous site put an innocuous version in well-known and a more specific, scary version based on http-equiv hoping that most people won't look into it but could use it as an out 17:45:03 wileys: Yahoo! has had platforms with lots of different publishers 17:45:28 ... in P3P, there was a punishment for silence (cookie-blocking and security settings for lack of Compact Policy) 17:45:50 ... was a mess for GeoCities where increasingly sophisticated publishers used that 17:46:21 ... in DNT today, publisher is not punished for silence, for not saying anything about DNT 17:46:57 ... good outcome will be for platforms to create configuration options for publishers, which could include DNT settings 17:47:26 (in addition to onboarding config, also need to bring exisiting content publishers through — and have a way to denote “we have no idea” for legacy sites that are basically abandoned) 17:47:37 present+ dsinger 17:47:38 ... make DNT status that's discoverable prior to loading content 17:48:14 https://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html 17:48:21 currently headers are optional 17:48:42 for what it’s worth — i don’t object to platforms retaining control of options for their publishers. just against publishers that don’t get it right all the way down the stack, and users should know which party promises which things. 17:48:46 fwiw I currently think I agree with Shane. Allowing hosted sites to bypass the hosting org. seems really dangerous 17:49:30 dsinger - i don’t think we should. i’d like each party responsible only for what they do. asking a publisher to speak for their hosting platform is equally daft. 17:50:17 schunter: would be fine having 5 tracking status resources, default to the one without id 17:50:26 … if manditory that’s a change we should make. 17:50:39 … if there’s no header (id?) it’s the default 17:50:59 mike: if host can’t return a header, defaults to hoster’s? 17:51:01 Check: headers should not be mandatory. If the header is absent, then the default TSR is used. 17:51:12 Schunter, makes sence to me, this way it is clear what tsr is the default 17:51:17 If you have many TSRs with IDs, then a header would be needed to point to one specific ID. 17:51:48 mike: if we have a TSR, fine, if not generate JSON on the fly (missing parts of this) 17:52:23 scribenick: npdoty 17:52:32 fielding: if you receive HTML page — not sure what the tech means would be. have an obj in the DOM that the JS would set a value that’s the tracking status response 17:52:43 fielding: could potentially have an object in the DOM, that includes the full content of the tracking status JSON 17:52:55 I have an update on Mozilla - not sure if you want that in IRC or verbally... 17:53:30 moneill2: could put text together to consider 17:53:45 fielding: we could, but I'd still prefer to just using site-wide well-known resources 17:54:07 moneill2: I'm trying to make it easier for those server folks to implement 17:54:18 fielding: concerned that making it easier for them in that way may not be better for the user 17:54:28 q? 17:54:33 q- 17:54:52 q+ 17:55:02 moneill2: can provide text alternative to be discussed on the list 17:55:32 dsinger: if someone would like to write a short document to enabled hosted sites / publishers, that would be a useful piece of education for industry 17:55:57 ls 17:55:59 ... here's a way to configure apache so that different sections of your served site have different TSRs and status-ids 17:56:01 q? 17:56:01 It depends on the depth of the publishing platforms openness - this would not work on Tumblr - but may work on several GoDaddy options 17:56:21 q- 17:56:26 fielding: planned once we have a stable spec; either a feature of the server or documentation on how to do it 17:56:30 +q 17:56:38 schunter: next time, I'd like to figure out how to close it 17:56:41 ack wileys 17:58:03 wileys: talking with Mozilla about participation 17:58:05 I’d leave it out if that’s okay 17:58:10 That was good 17:58:13 :-) 17:58:35 Topic: Implementation Report 17:58:52 schunter: want to get an update from w3c about status, different implementations, etc. 17:58:56 ... will discuss next time 17:59:00 Need the Exceptions API for us to show value to the ad ecosystem 17:59:25 beautiful 17:59:50 Either works for me 18:00:04 Okay - March 6th it is 18:00:10 schunter: next call March 6 18:00:11 better to have Nick than me 18:00:17 Thank you! 18:00:25 [adjourned] 18:00:29 wileys has left #dnt 18:02:58 and someone should update the minutes links on https://www.w3.org/2011/tracking-protection/ 18:08:57 trackbot, end meeting 18:08:57 Zakim, list attendees 18:08:57 As of this point the attendees have been npdoty, moneill2, Bert, aleecia, wileys, alantoner, fielding, schunter, dsinger 18:09:05 RRSAgent, please draft minutes 18:09:05 I have made the request to generate http://www.w3.org/2017/02/13-dnt-minutes.html trackbot 18:09:06 RRSAgent, bye 18:09:06 I see no action items