17:15:26 RRSAgent has joined #dnt 17:15:26 logging to http://www.w3.org/2017/02/06-dnt-irc 17:15:28 RRSAgent, make logs world 17:15:28 Zakim has joined #dnt 17:15:28 I support exceptions too - but need a browser to implement them for testing 17:15:30 Zakim, this will be TRACK 17:15:30 ok, trackbot 17:15:31 Meeting: Tracking Protection Working Group Teleconference 17:15:31 Date: 06 February 2017 17:15:57 basic discussion: IE implemented an older version of API, we could make that the standard and be done. or we could come up with what we like and hope to get enough interoperability to test via privacy badger & Mike’s extension 17:16:17 Mike suggests without a site specific API there’s not much point to DNT 17:16:41 (not sure who’s speaking now, dsinger?) points out we could tag it as at risk from lack of adoption 17:16:50 yes: dsinger talks 17:16:57 Which browsers do we have on the call any longer? Dave = Safari. Any others? 17:17:41 q? 17:17:41 a) change to promises b) mark at-risk c) catalyze the conversation somehow (don’t know how) to deal with the “after you Alfonse" 17:17:48 mike suggests yes, a publisher would be good, and ePriv reg could be relevant due to browser req to convey consent since cookie banners / window shade are no fun 17:18:11 q+ 17:18:11 cookie banners = window shade / eyebrow 17:18:13 (thanks, my scribe skillz have fallen off a cliff) 17:18:30 eyebrow! new to me, funny 17:18:32 ack ds 17:18:35 ack rv 17:19:13 How do we get MSFT Edge, G Chrome, and Moz FF back on the calls? 17:19:27 rvaneijk, perhaps a seperate way to do consent via cookies. problem: still a lot of pop up dialogs on purposes & 3rd parties. not an automatic mech. also transitivity of cookies in real time bidding is problematic. 17:20:06 Cookies get cleared too easily - would rather a hardened setting in the browser - otherwise no value in implementing DNT or Exceptions 17:20:38 vincent_ has joined #dnt 17:20:39 rvaneijk, could do DNT with cookie consent but haven’t seen finished proposals. automated consent through browser settings is in ePriv to reduce cookie banners. we could be adding to a cookie wall reality like in NL now, an accept-all or get nothing approach, which isn’t in the interst of users or publishers. 17:21:25 Agree with Rob - DNT/Exceptions are a better option than a cookie - as long as they survive cookie clearing and the publisher gets to control the UX with their users 17:21:31 rvaneijk, DNT could fit with ePriv, Art29 will have an opinion soon plus negotiations over ePriv over the summer. ??? will publish as well on DNT 17:22:06 +schunter 17:22:20 rvaneijk, Art29 looks beyond DNT and could also include a cookie mechanism but Rob’s personal opinion is cookies won’t out-perform DNT 17:22:40 mathais, cutting out for me 17:22:51 Same here - back to normal now 17:23:11 schunter, we draft options like normal, show how they operate, check with W3C (?) if it’s good enough 17:23:30 schunter, would be reluctant to attach our fate to browsers implementing the API 17:23:53 mikeoneill, should we get Heather West back on the calls? 17:24:06 ... Push alternative validation strategy in parallel to working with the browsers and major sites. 17:24:15 shane, know Moz is still into DNT not sure who they’d assign to the WG. could reach out and ask 17:24:20 schunter, please 17:24:39 wileys, Yahoo supports DNT for Firefox, that’s public. 17:25:05 mikeoneill, chairs could please request browsers send people again. 17:25:44 schunter, need contact points. have Adrian but MSFT is at the point of “publish and we’ll implement.” don’t have current for Mozilla. 17:25:57 I’ll speak with the GC Mozilla (ex-Yahooer) 17:26:10 (all of the Mozilla folks I know who would be involved are long gone) 17:26:40 schunter, have Mike’s plugin plus subset of implementation from IE, is this sufficient for being done? 17:27:02 mikeoneill, API and site-specific resource with config property would be nice 17:27:17 schunter, don’t want nice want minimum exit criteria 17:27:23 3 interoperating implementing each feature 17:27:44 (not sure who’s speaking) should be in the charter. A plug in is a weak strategy. Should have at least one browser. 17:28:24 schunter, setting up a meeting (internal to W3C?) to figure it out 17:28:42 sorry david, used to know your voice reliably 17:29:49 schunter, API and promises, next on the API. callback is easier and more developer friendly sayth Mike. reasons against: API needs to be changed, but need to change it anyway. reason against: not clear what the callback means, what it should signal to the user agent. 17:30:05 mikeoneill, edited the text and sent to the mailing list. 17:30:24 + 1 - I’m okay with the addition of promises. What happens if a UA doesn’t support promises? 17:30:39 … promise solves: webapps that are javascript-based, you ask for something and you want to make sure it’s acted upon when (before?) you do the other thing. 17:31:14 … store & remove exceptions returns a promise that resolves to (?) 17:31:42 thought we already discussed this. by changing to promises we invalidate the only native implementation we have (IE), a minor snag. but we should do it, mark at-risk, and deal with Alfonse. 17:31:43 … could ignore the return and carry on. the confirm returns a string, the value of the DNT header — wait, no, it doesn’t, it’s a boolean. anyway - 17:31:51 … promise resolves to that string or bool 17:32:12 … handles being asynch 17:32:21 I’m also okay with the addition of promises. 17:32:24 schunter, any reasons not to change? 17:32:29 +1 ok with it 17:33:18 schunter, requires change to our API but we’re going to make other changes, so let’s add the promises as consens and put the whole API tagged as at risk. if no one implements, disappears anyway. 17:33:38 wileys, what if a UA doesn’t support promises in their Javascript imp? 17:34:01 ... and what about mobile browsers, do they support promises? 17:34:10 mikeoneill, ignore it, it’s an object. they’re supported directly now. older version just gets an object. 17:34:25 q+ 17:34:27 … don’t think it matters which version of JS you have, works 17:34:52 wileys, we have versions without json support, is important to support those env, but if nothing will break, we should be ok 17:35:14 Okay 17:35:24 q? 17:35:25 mikeoneill, API would return a promise and not a string or boolean or whatever it is. but hardly anyone’s implemented it…. 17:35:50 rvaneijk, shall we test mobile browsers supporting the promise? 17:36:15 mikeoneill, sure. haven’t implemented it yet. know iPhones will be ok, but could try out others too. 17:36:45 Conclusion: Consensus seems to be that it is OK to introduce promises as returns. I will double-check via email. 17:37:02 … site-specific consent is important from a user point of view (more likely to give consent). could be set of sites or set of environments 17:37:09 schunter, different topic? 17:37:11 multi-domain is already supported in Site Specific Exceptions 17:37:35 mikeoneill, could be implemented in JS libs that emulate the API if the browser doesn’t support DNT directly 17:37:59 mikeoneill, could get expressions of consent to work anyway without browser implementation 17:38:12 vincent__ has joined #dnt 17:38:36 … would be quite nice to have a version of DNT JS property, how JS reads when DNT is set or not, that returns an event rather than just a string. you can’t implement it in a library unless you process it as an event. 17:38:45 … will write this up as a new issue. 17:39:11 schunter, have agreement that returning promises is ok. will close this as an issue, take up the rest as a new issue. 17:39:24 Issue 6 is closed; promises will be returned. 17:39:34 +q 17:39:40 q- 17:39:48 wileys, adding scoping to web-wide 17:40:24 dsinger, site-specific impelementations and discussion with Roy about 3rd party cookies as a tough way to implement. put a proposal up for that. 17:40:43 ^dsinger^mikeoneill 17:41:27 mikeoneill, web-wide consent is too broad, if you could limit it in some way it might be useful to the advertising community — e.g. be able to say members of (IAB or other) groups with promises 17:42:17 wileys, lone voice for industy but don’t want to break original web-wide. a scoped version would not be a bad addition, a nice option for publishers. will support if it’s not a one or the other. 17:42:27 schunter, could be optional scoping 17:42:31 q+ 17:42:37 -q 17:42:58 dsinger has joined #dnt 17:43:01 mikeoneill, ok with both. would have 3rd party get DNT:0 on some but not all first party websites. 17:43:13 ??, unclear on the use case, what problem to solve? 17:44:08 mikeoneill, once you say to example.com “accept everywhere” then users might not agree, since they don’t know where tracking goes and web history can be — 17:44:39 I think a use case would be 3rd parties asking "I'd like to track you on these websites: A,B,C..". I think it make sense, some users may grant this type of exception but refuse web wide. 17:44:56 rvaneijk? don’t understand use case. If I tell FB yes, track me anywhere the like button appears, then why a limited web-wide exception, seems a contridiction in terms 17:45:15 I see a use case... waiming the queue 17:45:26 mikeoneill, limits web-wide tracking to a set of parties in an org 17:45:40 (sorry David, you sound like you’re speaking from underwater) 17:46:19 mikeoneill, i’ll put it on paper and you can have a read. If consent is required for tracking, and site-specific we need to support, but we might want an intermediate form of web-wide that users might be more likely to agree to 17:46:49 I need use-cases, and to be convinced that we could explain to a user what they are being asked. This sound complex to me 17:47:11 q+ 17:47:37 schunter, see your point, would be nice, but would need a specific use case. Otherwise the spec gets too complex. Need a user who wants it, or a reason things break if you don’t have it. Just saying it’s nice would be good to have actual end users requesting it 17:48:12 … to keep us on track, let’s do other things and get adoption, then add in version 2 after we get feedback 17:48:23 … keep the momentum and do minimal changes 17:48:24 momentum 17:48:24 q? 17:48:58 … new features, reluctant to add, don’t want to start from scratch 17:49:27 mikeoneill, ok, will wait for someone else to step forward. other issue is site-specific should be verifiable and transparent, put up already. 17:49:29 q? 17:49:39 dsinger, server or client side? 17:50:08 mikeoneill, server. can register site-specific by user agent, but to implement — 17:50:21 dsinger, they don’t need to implement, they get DNT:0 17:50:21 q- 17:50:55 mikeoneill, third party gets DNT:0, places a cookie, can now track on other sites beyond the site-specific exception 17:51:17 dsinger, look at the header do NOT (cache) that you had DNT:0 before. add to spec. 17:51:27 wileys, already in the spec now 17:51:54 dsinger, whole thing relies on trust, header exception requires trust 17:52:09 mikeoneill, at the moment. hard to implement 17:52:22 (going in circles a bit here) 17:52:52 mikeoneill, you get DNT:0 as an embeded third party for a site-specific consent but you don’t know it’s site-specific 17:53:08 dsinger, how do you know what? you can track them there. 17:53:24 schunter, we had this discussion before. 17:53:24 Each transaction is evaluated independently 17:53:49 vincent_ has joined #dnt 17:53:49 … if you get a DNT:0, you can track. you don’t know if it’s always or site-specific. 17:53:55 API allows a server to query to exception mode 17:53:55 q+ 17:54:12 repetition of prior points 17:54:29 +q 17:54:56 mikeoneill, if you place a cookie you get it sent back to you on other sites, so it’s no longer site-specific consent 17:55:04 dsinger, it is. 17:55:19 mikeoneill, ok on DNT:1 it’s DNT:0 that’s the issue 17:55:47 schunter, get cookie back on another site and in theory could track you because i get the cookie back, -- 17:56:16 dsinger, you’re allowed to know you have a DNT:1 and it’s ok if someone visited yahoo because they agreed in the past 17:56:16 q? 17:56:22 ack wil 17:56:45 wileys, already an API to confirm a site-wide exception to request from client. 7.5 webwide, 7.4 site wide 17:56:46 sorry for q-jumping 17:56:54 …always a call to confirm why you got the DNT:1 17:56:59 eek, DNT:0 17:57:23 mikeoneill, can use to confirm, i’ll think about that. 17:57:33 wileys, going deep but it’s there! 17:57:41 ack alee 17:58:09 but there seems to be confusion here: yes, if you set a cookie under DNT:0, you will see that cookie on sites that send DNT:1. This is not a contradiction. You were allowed to track the user on the site that sent DNT:0, that’s what it means. On every interaction, you behave according to the DNT header received in that transaction. 17:58:31 aleecia, users can revoke consent at any time already, so DNT can’t persist already. 17:58:53 mikeoneill, will think about it more 17:59:42 wileys, shift to 13th? 17:59:55 dsinger, pos jury duty 18:00:13 us holidays & such 18:00:29 schunter, will reschedule to next week, on the 13th feb 18:00:31 wileys has left #dnt 18:00:49 sorry for my pathetic scribe attempt, particularly to dsinger 18:58:42 dsinger has joined #dnt 20:09:25 Zakim has left #dnt