Tracking Protection Working Group Teleconference -- 15 Oct 2014

<trackbot> Date: 15 October 2014

<npdoty> scribenick: moneill2

TPE Last Call

last few issues

justin, issue 262

<justin> issue-262?

<trackbot> issue-262 -- guidance regarding server responses and timing -- pending review

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/262

justin, real time bidding

<justin> http://lists.w3.org/Archives/Public/public-tracking/2014Oct/0064.html

shane: how do we deal with dnt in environs where downstream has no access to\ UA
... in EU Rigo talked abour "transative" requirement
... receiver must forward DNT / TK toupstream/downstream

shane, could be conflict if use passes DNT 1 but direct domain has DNT:0

shane, makes sense that processor must relay that in status response

shane, dont know how technically to make it work

<npdoty> in most cases, though, the status response isn't an immediate response from the server. would we expect all servers to make TSR requests and then construct TSR responses on their behalf?

shane: a bid goes to 10 server, each will respond with bid, ad exchange sent forward its DNT signal
... other parties may have different UGE, if win bid their ad goes forward. So theie tr: should go to UA
... UA gets conflicting signals
... not at same time. server to server. the last transaction applies

<dsinger> would like to understand, does the exchange act as a proxy to the winning bidder, or does it re-direct the UA? I assume the problem is the former, and the winning bidder (thinks it) has an exception, while the exchange does not

justin: how will exception gets revoked

shane: then no last transaction,

<dsinger> is it at all likely that the winning ad bidder has a web-wide exception?

<npdoty> dsinger, it seems to me that Shane is suggesting this just for the server-to-server case, not the 301/302 redirect situation

<WileyS> Correct - just in server-to-server

vincent: question, i send DNT: 1 to server, server should not be allowed to share

shane: just facilitating delivery of ad, no info shared

<dsinger> to npdoty: right, in the re-direct case the winning bidder ends up communicating directly with the UA. It’s where the exchange stays in loop (like a proxy) that we have an issue

shane, how do downstream servers know who the user is (w/o UID sharing)

vincent: if ad exchange respects DNT, but down stream dony, third-party would hav eto honoure

shane: ad exchanhe actingh as data processor, endpoints are controllers
... within same transacrtion primary endpoint is processor not controller
... loss rules and win rules. bidding
... contractually endpoints not allowed to keep data

<npdoty> it sounds like the suggestion is that the ad-exchange is a processor or even our "service provider" to the other parties [?]

shane: scenraio processor acting as frontend to many controllers

<dsinger> but if the exchange promises to honor it, it had better (a) relay it to (b) servers that will also honor it

shane: not goal of DNT

<Zakim> npdoty, you wanted to ask is this entirely server-to-server, or does the winning bidder ever interact with the end user via HTTP?

justin: we are not trying to defaet ad exchange system, ad might need to collect info for billing purposes

nick: only talking about server- server convos

<WileyS> Correct - this is not meant to cover redirection

nick: question to shane

<WileyS> Correct - the Ad Exchange is a Service Provider

nick: ad exchange working on behalf od one of the endpoints i.e. the winner
... tpe designed tr rresponse not always real-time response

<justin> FWIW, I think it would be hard to argue under EU law that adx is a "processor." But I get the notion that they're acting as a pass-through here.

nick: ad exchjanhge has to check and get response? q to shane

<fielding> I don't see any difference. The exchange receives the HTTP request. The exchange is responsible for its own TSR. If the exchange shares the data received with third parties, then the exchange is responsible for reporting the worst case to the user in its own TSR.

shane: difficulty is async process. some cases ad delivered by exchange, i agree stst resp not bbuilt to work for this use case

<vincent> justin, indeed they would not qualify as a processor

shane: dont know how to deal with disconnect

<Zakim> dsinger, you wanted to ask how likely this is

david: one of the winners supplies ad, thinks it has OOBC or would have received DNT:0 if it was talking directly

shane: yes

david: ad server has web-wide UGE. This is a little unlikely. If endpoints want to directly interface with user then they should, how ad is converyed is opache,
... this is unsolved in first version of DNT

roy: user has opportunity to interact with ad exchange and noone else. In this situation it is excahnges responsibility

<npdoty> service providers have to know how to respond on behalf of their contractees, right?

shane: ad exchange is neutral in transaction

david: if it promises to bey DNT it needs to get others to honour

shane: David is saying if it oobeys DNT then all bidders must also
... we cannot force them to take position
... dangerous for biz to do that

<WileyS> +q

roy: ad exchange is not neutral, it has to take responsibility, like any other company in biz, if they cant they cant support DNT that is the end of it

<Zakim> npdoty, you wanted to ask about tracking status response and timing, as was the original suggestion

justin: how under current defintion can ad exchange sent any response

nick: back to timingh. in case of prefetch, ad exhange has to respond with sih=gnal reflecting union of its contractees
... ad exchanges cannot claim ahead of time, bur they can send after event indication

shane: all parties have contracts, in most cases ed exchanges cannot force changes or 100% coverage. lets adobe analytics as example

<dsinger> so we have TWO problems (a) ad exchanges don’t know if all their bidders support DNT and (b) the winning bidder might think it has OOBC or a web-wide exception

<npdoty> dsinger, I think the issue was asking about (a), though Shane's text is about (b) as well

shane: does adobe: respond as themselves or the party they are acting for

<fielding> The only thing that TPE requires here is that the response from the exchange (the only HTTP server) reflects how that exchange deals with the data. If the exchange cannot control what its bidders do with the data in the presence of DNT:1, then they cannot claim in their own exchange TSR that they are obeying the restrictions of DNT:1.

shane: its not fair to say exchanges need to support DNT to relay their contractees responses

<dsinger> how much does the “?” tracking status help? <http://www.w3.org/TR/tracking-dnt/#TSV-?>

<npdoty> yeah, I think it does

justin: how about privacyBadger. What can an intermediary send back. No auditability. How does UA control who gets info

<npdoty> if the exchange sent a "?" in a pre-fetch request, and then sent a Tk header in response

shane: many ads today go through exchange so we need to deal with this

justin: can a winning bidder say they have consent

<dsinger> So, the tracking status of the exchange says “?”. When the ad is served, the actual status from the bidder is sent.

<dsinger> we need to cover the case of request-specific TSRs. Roy, can you help?

shane: winner selected, what is the response from bid winner or processor (ad exchange) wo received the DNT request

<npdoty> dsinger, I don't think request-specific TSRs is a problem. that's only if a response says, "use this particular code"

shane: bid winner can represent themselves directly to UA

justin: person serving this ad either honours DNT or has consent

shane: we might have to pass on the domain of the bid winner
... ad exchange does not want to be the middle man.

<fielding> Shane, when acting as a service provider there is a contract that specifies who controls the data and we can respond with the TSR on behalf of that contractee (first party) according to their instruction. The only ways we can cover your use case is by the exchange sending the set of all potential TSRs for all potential bidders (which is known to be impossible) or by the exchange providing a worst-case TSR to the user based on its bidding agreement requirements.

<npdoty> I think the "?" is appropriate, and then send a Tk response header on behalf of the winning bidder

justin: we spent abunch of time on this, continue to think, iterate, understand issue. should TSV need updating etc.

<WileyS> Roy, Yikes - those are both horrible outcomes. Other options?

<npdoty> ... or if an ad exchange does have contract agreements ahead of time, it can give something more specific

<npdoty> yes, will follow up in email.

<justin> isssue-268?

<WileyS> Nick, I like that option better. :-)

<dsinger> issue-268?

<trackbot> Sorry, but issue-268 does not exist.

<fielding> WileyS, yes -- when DNT:1 is received, do a redirect instead of a gateway.

<npdoty> issue-266?

<trackbot> issue-266 -- automatic expiration of a tracking preference exception via API parameter -- raised

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/266

<npdoty> scribenick: npdoty

<dsinger> …was trying to keep life simple.

justin: discussion on the list. pushback about whether it's necessary for interoperability

<WileyS> Roy, that would make the ad serve fail as there is nowhere to redirect to if the ad creative for that winning bid is housed on the ad exchange

justin: nick said it was mostly applicable to web-wide exception

<fielding> Shane, wouldn't it then be covered by the exchange's TSR? You would only need to redirect to winning bidders that you do not trust.

dsinger: if the user sends a DNT:0 and a cookie used for expiry is absent, the non-javascript party can't determine whether the request should expire
... could add an optional expiry parameter
... added complexity

moneill2: user agents have cookie-like expiry code already, for cookies

<WileyS> Roy, I don't believe this is a question of "trusting" my customers - its more a matter of the actual mechanics of serving ads from an ad exchange. If the creative is stored on the exchange there is never an option to "redirect" to ad delivery.

moneill2: and have to track the UGEs already, in an object model
... transparency, UAs can show that detail to the end user
... if you try to do it with cookies, nightmare of synchronicity
... have the UA implement the complexity, rather than spreading it out

fielding: no harm for it, except for complexity for the browser
... might as well include the cookie-like behaviors

<WileyS> EU Laws will likely change in the near future - I think we can manage with existing technology and come back to this if the EU Data Protection Regulation requires Expiry as the A29WP believes the current ePrivacy Directive strongly recommends.

<dsinger> it was just complexity and respecting people who have already implemented, on my part

<justin> npdoty: What is the likelihood this will be implemented? Will the browsers implement and will websites use? Will user agents push back on the complexity?

<vinay> I agree with Shane. Websites either already are, or have, built out solutions to address current laws. Since there is no support for this now within browsers, websites will not be able to rely on this for at least the immediate future.

<justin> npdoty: We could add expiration like cookies, but we can't cover every possible use case (login, privacy policy changes, etc.). It will be up to the site to order expiration --- API is just about storing.

<fielding> Honestly, I would still prefer to ditch the whole exceptions framework and just use specially-named cookies that browsers can avoid clearing if so configured.

<scribe> scribenick: npdoty

<dsinger> cookies don’t cover site-wide. I agree, I think web-wide is very questionable

justin: could get rid of exceptions entirely (per fielding)
... could try to hear more from dsinger or adrian regarding UA implementation?

<WileyS> Roy, wouldn't this require a change to the HTML standard to support non-clearable cookies - and in turn wouldn't that break EU guidance?

dsinger: could remove web-wide exception (and just expect it to be handle by cookies), or add expiration parameters to both versions of the call

<WileyS> Pure 3rd parties need web-wide exceptions!

justin: please send in email.
... on dsinger's remaining TPE LC issues

dsinger: responses from anne notes using an older style, cookie-like and cross-origin matching restrictions

<WileyS> Any suggestion to remove UGEs entirely or remove web-wide exceptions will further doom the DNT standard. If the target of the standard (almost entirely 3rd parties) have left with no tools to provide balance in the standard no one will adopt DNT.

dsinger: but I aren't heard what a better way would be, with the more modern model

<fielding> WileyS, alternatively (regarding earlier conversation)

<fielding> , ensure that the bidders are not given enough information to track the user

dsinger: it sounds like the dynamic matching wouldn't work

<moneill2> nick, i can do it agin now if you want

<scribe> scribenick: moneill2

Compliance issues

<justin> issue-148?

<trackbot> issue-148 -- What does DNT:0 mean? -- raised

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/148

<npdoty> action-460?

<trackbot> action-460 -- Nick Doty to Add language on dnt:0 re scope of consent preference -- due 2014-10-15 -- OPEN

<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/460

justin: 3 issues i want to talk about, issue 148
... question to nick

<WileyS> Roy, that breaks the concept of bidding. For a bidder to understand the full context of the transaction to place the most accurate bid we need to give them enough information that arguably could be used to "track" the user. That's why all exchange contracts carry very specific clauses on "bid loss" rules.

nick: not yesty

justin: issue 24,

<justin> issue-24?

<trackbot> issue-24 -- Possible exemption for fraud detection and defense -- pending review

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/24

<npdoty> from dsinger: http://www.w3.org/mid/65CF2BE9-E560-4904-BF66-AF7C2BFE9627@apple.com

justin: proposal ongraduated response

jjustin: shane said he was fine with, question to nick

<WileyS> +q

nick: if we can just note it is non-normative maybe were done

<dsinger> I am not wedded to my precise wording if Nick or anyone wants to suggest edits or an alternative

shane: give voice support to davids language.

<fielding> Shane, I don't think people have figured out yet that looking up the tracking preferences before every request is a performance issue for browsers and will lead to UGE not being implemented. Cookies are already implemented and are already used for consent. Yes, it would require some update to browser cookie policy to allow certain cookies to not be cleared, but that won't be a problem if the cookie value is limited to a fixed value (0/1).

shane: all fixed, so supportive

justin: ok with mentioning term?

shane: yes

<npdoty> I don't think the current language is normative or prescriptive...

justin: q to nick to check this,

<dsinger> note that the proposal is 2-part: shorten the first paragraph and make the second one clearly examples and non-normative

<WileyS> Roy, has IE reported this as being a performance issue since they do it already today? I've not heard that issue raised yet from a browser vendor.

justin: we alo sounf to be on same page

nick: i can do a diff of mine and Davids langauge

<WileyS> Roy, I think the cookie path has other complexities related to 3rd party cookie blocking versus web-wide exceptions - and then the "non-clearing" elements from a regulatory perspective will likely create issues.

justin: if noone objects on principle, i incline to go with this, other folks take a look at at

<npdoty> Shane's concern: don't want it to be normative, want to emphasize that graduation can be in either direction, explicitly notes data minimization

<WileyS> I don't strongly prefer this - I'd still rather remove the whole non-normative section.

<npdoty> WileyS, did I get those changes right?

<WileyS> Nick, I believe so

<npdoty> thanks

<justin> issue-235?

<trackbot> issue-235 -- Auditability requirement in Reasonable Security section -- raised

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/235

<WileyS> 2 mins :-)

justin: last issue 235 audibility
... shane he wanted to carry on with this

<WileyS> I want to remove the "auditable" element as I don't believe it has any value.

justin: do group mambers still want clause about audibility

<npdoty> sentence in question: "That party SHOULD ensure that the access and use of data retained for permitted uses is auditable."

justin: lrts wraop up, nick send ideas on issue 262,

<fielding> Shane, I don't know if Adrian has looked at the overhead issue. I know that the chrome and mozilla teams will, if they ever implement. Yes, the problem with cookies as a solution is the site-specific consent, unless someone institutes double-keyed cookies as well.

<dsinger> thx

<fielding> npdoty, the problem with sending "?" is that the final response still has to be applicable to that same resource for 24 hours. perhaps we need to change that?

<npdoty> trackbot, end meeting

- DRAFT -

Tracking Protection Working Group Teleconference

15 Oct 2014

Attendees

Contents

TPE Last Call

Compliance issues

Summary of Action Items

Scribe.perl diagnostic output