– DRAFT –
Tracking Protection Working Group Teleconference

<trackbot> RRSAgent: make logs world

<wileys> I support exceptions too - but need a browser to implement them for testing

<trackbot> Zakim: this will be TRACK

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

Mike suggests without a site specific API there’s not much point to DNT

(not sure who’s speaking now, dsinger?) points out we could tag it as at risk from lack of adoption

<schunter> yes: dsinger talks

<wileys> Which browsers do we have on the call any longer? Dave = Safari. Any others?

<dsinger> a) change to promises b) mark at-risk c) catalyze the conversation somehow (don’t know how) to deal with the “after you Alfonse"

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

<wileys> cookie banners = window shade / eyebrow

(thanks, my scribe skillz have fallen off a cliff)

eyebrow! new to me, funny

<wileys> How do we get MSFT Edge, G Chrome, and Moz FF back on the calls?

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.

<wileys> Cookies get cleared too easily - would rather a hardened setting in the browser - otherwise no value in implementing DNT or Exceptions

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.

<wileys> 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

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

<schunter> +schunter

rvaneijk: Art29 looks beyond DNT and could also include a cookie mechanism but Rob’s personal opinion is cookies won’t out-perform DNT

mathais: cutting out for me

<wileys> Same here - back to normal now

schunter: we draft options like normal, show how they operate, check with W3C (?) if it’s good enough

schunter: would be reluctant to attach our fate to browsers implementing the API

mikeoneill: should we get Heather West back on the calls?

<schunter> ... Push alternative validation strategy in parallel to working with the browsers and major sites.

shane: know Moz is still into DNT not sure who they’d assign to the WG. could reach out and ask

schunter: please

wileys: Yahoo supports DNT for Firefox, that’s public.

mikeoneill: chairs could please request browsers send people again.

schunter: need contact points. have Adrian but MSFT is at the point of “publish and we’ll implement.” don’t have current for Mozilla.

<wileys> I’ll speak with the GC Mozilla (ex-Yahooer)

(all of the Mozilla folks I know who would be involved are long gone)

schunter: have Mike’s plugin plus subset of implementation from IE, is this sufficient for being done?

mikeoneill: API and site-specific resource with config property would be nice

schunter: don’t want nice want minimum exit criteria

<schunter> 3 interoperating implementing each feature

(not sure who’s speaking) should be in the charter. A plug in is a weak strategy. Should have at least one browser.

schunter: setting up a meeting (internal to W3C?) to figure it out

sorry david, used to know your voice reliably

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.

mikeoneill: edited the text and sent to the mailing list.

<wileys> + 1 - I’m okay with the addition of promises. What happens if a UA doesn’t support promises?

mikeoneill: 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.
… store & remove exceptions returns a promise that resolves to (?)

<dsinger> 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.

mikeoneill: 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 -
… promise resolves to that string or bool
… handles being asynch

<rvaneijk> I’m also okay with the addition of promises.

schunter: any reasons not to change?

+1 ok with it

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.

wileys: what if a UA doesn’t support promises in their Javascript imp?

<rvaneijk> ... and what about mobile browsers, do they support promises?

mikeoneill: ignore it, it’s an object. they’re supported directly now. older version just gets an object.
… don’t think it matters which version of JS you have, works

wileys: we have versions without json support, is important to support those env, but if nothing will break, we should be ok

<wileys> Okay

mikeoneill: API would return a promise and not a string or boolean or whatever it is. but hardly anyone’s implemented it….

rvaneijk: shall we test mobile browsers supporting the promise?

mikeoneill: sure. haven’t implemented it yet. know iPhones will be ok, but could try out others too.

<schunter> Conclusion: Consensus seems to be that it is OK to introduce promises as returns. I will double-check via email.

mikeoneill: 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

schunter: different topic?

<wileys> multi-domain is already supported in Site Specific Exceptions

mikeoneill: could be implemented in JS libs that emulate the API if the browser doesn’t support DNT directly

mikeoneill: could get expressions of consent to work anyway without browser implementation
… 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.
… will write this up as a new issue.

schunter: have agreement that returning promises is ok. will close this as an issue, take up the rest as a new issue.

Issue 6 is closed; promises will be returned.

<wileys> +q

wileys: adding scoping to web-wide

dsinger: site-specific impelementations and discussion with Roy about 3rd party cookies as a tough way to implement. put a proposal up for that.

^dsinger^mikeoneill

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

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.

schunter: could be optional scoping

<wileys> -q

mikeoneill: ok with both. would have 3rd party get DNT:0 on some but not all first party websites.

??, unclear on the use case, what problem to solve?

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 —

<vincent__> 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.

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

<rvaneijk> I see a use case... waiming the queue

mikeoneill: limits web-wide tracking to a set of parties in an org

(sorry David, you sound like you’re speaking from underwater)

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

<dsinger> 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

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
… to keep us on track, let’s do other things and get adoption, then add in version 2 after we get feedback
… keep the momentum and do minimal changes

<wileys> momentum

schunter: new features, reluctant to add, don’t want to start from scratch

mikeoneill: ok, will wait for someone else to step forward. other issue is site-specific should be verifiable and transparent, put up already.

dsinger: server or client side?

mikeoneill: server. can register site-specific by user agent, but to implement —

dsinger: they don’t need to implement, they get DNT:0

mikeoneill: third party gets DNT:0, places a cookie, can now track on other sites beyond the site-specific exception

dsinger: look at the header do NOT (cache) that you had DNT:0 before. add to spec.

wileys: already in the spec now

dsinger: whole thing relies on trust, header exception requires trust

mikeoneill: at the moment. hard to implement

(going in circles a bit here)

mikeoneill: you get DNT:0 as an embeded third party for a site-specific consent but you don’t know it’s site-specific

dsinger: how do you know what? you can track them there.

schunter: we had this discussion before.

<wileys> Each transaction is evaluated independently

schunter: if you get a DNT:0, you can track. you don’t know if it’s always or site-specific.

<wileys> API allows a server to query to exception mode

repetition of prior points

<wileys> +q

mikeoneill: if you place a cookie you get it sent back to you on other sites, so it’s no longer site-specific consent

dsinger: it is.

mikeoneill: ok on DNT:1 it’s DNT:0 that’s the issue

schunter: get cookie back on another site and in theory could track you because i get the cookie back, --

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

wileys: already an API to confirm a site-wide exception to request from client. 7.5 webwide, 7.4 site wide

<dsinger> sorry for q-jumping

wileys: always a call to confirm why you got the DNT:1

eek: DNT:0

mikeoneill: can use to confirm, i’ll think about that.

wileys: going deep but it’s there!

<dsinger> 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.

aleecia: users can revoke consent at any time already, so DNT can’t persist already.

mikeoneill: will think about it more

wileys: shift to 13th?

dsinger: pos jury duty

us holidays & such

schunter: will reschedule to next week, on the 13th feb

sorry for my pathetic scribe attempt, particularly to dsinger