Tracking Protection Working Group Teleconference -- 17 Dec 2014

<trackbot> Date: 17 December 2014

<scribe> scribenick: wseltzer

TPE Last Call Comments

justin: First issue, gateway, tracking status value

<dsinger> 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: Shane, any comments?
... Main issue whether we'll allow gateways to signal N or T

<WileyS> +q

justin: Roy said, sure, N, if they can say with conficence everyone theyre sharing with agrees not to track
... Vincent sent a note this morning (US time), saying it shoudl send G regardless

<fielding> removing those is fine with me … I was just trying to capture all the requested input

<WileyS> Agree to Roy only on "G", agree with Rob & T on removing T and N - disagree with Mike

WileyS: I agree with Roy on G

<justin> T = vincent

WileyS: I agree with Rob and Vincent on removing T and N
... G is a safer signal
... There may be edge cases where T or N work, but don't know that we want to go that route
... Disagree with Mike's comment from earlier today
... Want to keep the gateway as neutral as possible
... they don't build their own profiles; cross-site tracking only to degree they meet permitted uses

<moneill2> +q

<npdoty> moneill2, did you have a problem with just using the Tk response header from the bid winner?

WileyS: gateway not trying to take position for sites it services; let them speak for themselves
... spoke with other gateways, none retains info in a bid-loss scenario

<npdoty> thanks for checking on that, WileyS

WileyS: would only send G if if felt bid losers are retaining no tracking data; bid winner will respond for itself.
... That seems shortest way to say all 3 elements

justin: So, you'd be fine with proposed deletion of 2 paragraphs, ok with Roy's language?

WileyS: Yes, of course needing to see final language

justin: delta between Roy's description and permitted uses
... we should all be on same page on what gateway is permitted to retain

<WileyS> Gateways faciliate frequency capping

<fielding> ah, oky

justin: I thought other folks weren't expecting permitted uses by gateway

moneill2: 2 aspects in what I put on the list
... gateway has to extend preference
... but it can't tell difference between site-specific and general preference

<npdoty> I thought Roy’s text said you need to forward the “expressed preference”

<vincent> WileyS, could we have example of contract/ToS of ad-exchange to check the status of service provider? try to find some but it's hard to find except for doubeclick

moneill2: difference between gateway and normal situation is that there's no element on the page by which user can ID gateway
... consider polaris technical blocking, on what elements will it apply?

<WileyS> Vincent, those contracts are covered by NDA so I'm not able to distribute

moneill2: use the controller property as way for gateway to tell UAs which parties have received the data

<npdoty> I think a server can use the controller property that way right now, if it wants to

justin: vision of G....
... if the gateway is sending info and don't know what recipients will do with it, what shoudl they send?
... T, as Roy said?

<vincent> WileyS, is there a generic template (not an actual contract) that could use?

fielding: to Mike's concerns. When users sends DNT:1 to gateway, it's saying "you can share with other parties"

<npdoty> I think even without that paragraph in question, the server can send “T” back if it’s going to be tracking

fielding: so it doesn't matter whether it's site-specific or general

<justin> Fair point, thanks npdoty, I think that's right.

<justin> Though not sure why we shouldn't explicitly say it in the document.

<moneill2> +q

<vincent> could the gateway get a webwide exception anyway?

<WileyS> Site-wide would cover the exchange use case!

<WileyS> site-wide covers all parties on that site

<WileyS> Site X and it's partners...

<dsinger> If the hosting site (Newspaper) has a site exception, all 3rd parties on that site get dnt:0

<vincent> I also think that site-wide would cover Ad-X

dsinger: I can't see how if the gateway gets a DNT:0 it doesn't pass it on

fielding: that doesn't have to be part of our protocol

<Zakim> npdoty, you wanted to comment on the T response value

npdoty: even if we delete the T and G paragraph, we might have situations when G doesn't fit

<fielding> I mean, if the site has agreed to additional restrictions, then it should be telling the exchange through the exchange's API (usually the resource URIs)

npdoty: where you're not going to get more information via TK header

<npdoty> I think the “N” when all my gateway parties have already agreed is possible, but not a particularly important case

justin: Looking for something for an exchange to send back when it can't vouch for everything down the line

<fielding> BTW, we are talking about http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#TSV-G

vincent: perhaps add requirement that gateway should not seek sitewide exception
... I meant web-wide exception

<fielding> again, having permission from the user is not a concern of ours. Think Nielsen.

<npdoty> if it gets a web-wide exception by convincing me that it’s a really trustworthy site, sounds good to me

<npdoty> “we always work with this group of companies, and they make up a really good service”

justin: is it appropriate to ask someone working as an exchange to do something quite different

<vincent> ok, sounds good to me then

justin: Vincent, are you ok removing language around N, giving ability to send T?

<vincent> yes, fine with me

<npdoty> not removing language about T, but removing language about N

<fielding> Well, there is always the ability to not send G.

<npdoty> if you’re not tracking, you can send N, as described in the other sections

<fielding> Right, it is really just advice.

<vincent> sharing is tracking

<fielding> It could be a gateway that only exists on one party's site

dsinger: Need a note that transferring information to another party may be considered tracking?

justin: I thought it was clear in the definition of tracking, but add a note if you think useful

<vincent> "When a third party to a given user action receives a DNT:1 signal in a related network interaction that party MUST NOT collect, share, or use tracking data related to that interaction;"

<WileyS> I believe that's a TCS issue, not TPE

<dsinger> to Vincent, that seems pretty clear: a gateway asking another 3rd party to satisfy is necessarily sharing, isn’t it?

<WileyS> Correct - OOBC

<WileyS> OBC/UGE

<npdoty> I think we don’t have a solution for losing bidders to claim out-of-band consent, as they don’t have the ability to communicate that to the end user

<vincent> dsinger, yes hence the discussion about the service provider status

vincent: could we see a template of a contract with an ad exchange?

<kulick> How about we re-visit the definition of "tracking" ... ;)

vincent: not the confidential details

<WileyS> Another option would be to redefine the term "tracking" :-D (My x-mas gift to the working group)

<kulick> j/k

<npdoty> is this different from “service provider” definition that we already have settled?

vincent: TOS of ad exchange, so we could see if they're service providers

<npdoty> relevant section of “service provider” definition from compliance:

<npdoty> has no independent right to use the data other than in a permanently deidentified form (e.g., for monitoring service integrity, load balancing, capacity planning, or billing);

fielding: I used "service provider" from discussion; could instead replace with terms applying to gateways

justin: that sounds useful

fielding: we do use service provider in another definition, but not so important

<justin> issue-260?

<trackbot> issue-260 -- method for validating DNT signal from user -- raised

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

justin: sounds like progress, wait for the editors to come back with text

<npdoty> email from fielding http://lists.w3.org/Archives/Public/public-tracking/2014Dec/0020.html

<WileyS> The response doesn't meet industry's needs here and will continue to be the primary reason others will not support this standard voluntarily.

<WileyS> Can we apply a CfO here?

justin: Shane, do you want us to go through Call for Objections process on this?

WileyS: I believe we'd already covered this pre LC
... it came up again at LC

<npdoty> is there a way that WileyS or others would see a way that would meet those needs?

WileyS: since it already went through CfO, and chairs determined not to address; we're still getting objections
... I don't know if a CfO now will change anything
... We were hoping for a technical solution
... here, we don't have the multiple options on the table.

justin: chairs have said that of the options before the group, I agree with Roy's approach

<npdoty> I’m not sure which previous CfO is the relevant one

<dsinger> I think the response is “there is no other way it can be”, alas. There is no answer to “does the user really really really mean it?” (except asking the user again, which is always posisble)

<npdoty> if we don’t have plausible options, then I would agree that the CfO doesn’t really make sense as a process step

justin: if it's an issue blocking CR, say it then
... so I'd suggest we move on, close

Compliance issues

justin: Last issues in TCS, use of tracking

npdoty: I haven't made changes since last week, but several changes before last week's call

<npdoty> http://www.w3.org/wiki/Privacy/TPWG/Editorial_corrections

<fielding> I heard npdoty is keeping a list, like santa

issue-203?

<trackbot> issue-203 -- Use of "tracking" in third-party compliance -- open

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

npdoty: made some changes last week to address scope

fielding: still have to review. Likely concerns along the lines of what Vincent quoted

<npdoty> I would welcome any clarifications on that point (data collection that could only happen in one context)

fielding: will try to review this week

justin: I'll send email re orphaned issues

npdoty: I'd welcome good thorough reviews from folks. I'll try to make my changes before Christmas
... and then welcome re-readers

justin: encourage you all to re-read, report bugs and issues
... we'll send updated timelines
... Plan for TCS last call soon; as Nick says, open issues are editorial, not substantive

<npdoty> yeah, I think we’ll be ready for Last Call on Compliance in January

dsinger: You'll see an email "this is the LC candidate"?

<npdoty> sounds right to me, dsinger

justin: we can CR TPE before TCS to LC

<npdoty> (I agree that TPE can go to CR before)

npdoty: they don't have to go to CR at the same time

justin: we need to resolve the gateway issue; editorial changes to TPE
... think both can move forward in January
... when editors think docs are ready

[adjourned]

<npdoty> thanks wseltzer for scribing

<npdoty> happy holidays to all

<npdoty> trackbot, end meeting

- DRAFT -

Tracking Protection Working Group Teleconference

17 Dec 2014

Attendees

Contents

TPE Last Call Comments

Compliance issues

Summary of Action Items

Scribe.perl diagnostic output