Tracking Protection Working Group Teleconference -- 10 Dec 2014

<trackbot> Date: 10 December 2014

<npdoty> scribenick: moneill2

TPE Last Call issues

justin: issue 262 roys proposal

<npdoty> issue-262?

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

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

<npdoty> https://www.w3.org/wiki/Privacy/TPWG/Change_Proposal_Regarding_gateways_and_exchanges

fielding: tpe provides g response indicating server acting for multiple parties respone get back will be in header field
... only is tsr, not in header. If all recipients respond with N gateway responds with n
... contractual agreement that recipients could not receive tracking data

<fielding> http://lists.w3.org/Archives/Public/public-tracking/2014Dec/0013.html

justin: cant hear vincent

<vincent> trying to dial back, in case my wuestion was about the third paragrpah

npdoty: thanks to roy, main question do we need extra requirements, must be service provider?

fielding: question better addressed for shane

<fielding> http://lists.w3.org/Archives/Public/public-tracking/2014Dec/0013.html

justin: can shane take a look at rules for g

<npdoty> WileyS, we’re looking at Roy’s language here: http://lists.w3.org/Archives/Public/public-tracking/2014Dec/0013.html and I was unsure whether the service provider concept will work for the common exchange implementations

<justin> https://www.w3.org/wiki/Privacy/TPWG/Change_Proposal_Regarding_gateways_and_exchanges

vincent: my suggestion mabe covered by Roys? Will gateway either sends N or T (q to Roy) what about permitted uses, user cannot tell

justin: is concern about G sending N or T

<npdoty> I think Roy’s proposal suggests that the gateway sends T if it or its bidders is known to be tracking

justin: when gateway replies N

vincent: bidders may reply with C if they think they have consent

<npdoty> if the winning bidder felt it had out of band consent, then it would send back “C” in the Tk header

fielding: site might say it tracks in general,

<npdoty> right, G is a dynamic response (like ?), so it makes sense for cases where it might be N or might be C

fielding: if gateway has set of requirements that bidders dont track then it reasonable to respond N, otherwise G

<vincent> not really, it's not dynamic, the gateway send either N or T or G

fielding: it replies T if it know non selected bidders are tracking
... needs to be an indication if tracking is going on

<npdoty> should respond with a dynamic response (G, for example) if the Tk header will provide more information. otherwise, should follow the existing rules for T and N.

vincent: does gateway send T or G or N

<WileyS> fair - bid losers are not able to "retain" user level data but we do allow aggregate/anonymized retention to enhance bidding algorithms so other permitted uses should remain in place regardless - fair?

<npdoty> and if the gateway sends G, it must transmit a more informative value in the Tk response header (from the selected party, for example)

vincent: why not say only G response (others confuse users)

<npdoty> scribenick: npdoty

moneill2: 3 things

<justin> WileyS, if it's really deidentified, the data is out of scope

… on service provider, the gateway is saying it’s a service provider of the bidders. it needs kind of reciprocal agreement about not keeping data in some cases. so not exactly the same as service providers we’ve discussed before.

<justin> WileyS, TPE is clear about that.

<WileyS> Justin - I agree but if its not deidentified but only used for analytical purposes it should still be protected by a permitted use as well, correct?

<vincent> WileyS, it's not teh same when only one party receive the information and you know which one it is and when mulitple parties receive the request and you're not aware of it. Users should be able to see difference

… if the general preference is DNT:1, then you can’t utilize consent. [@@scribe may have missed@@]

<WileyS> Vincent - as long as there is no tracking occurring I'm not seeing the issue

… a whole range of bidders that may or may not be collecting data, need a way for the gateway to report that, because otherwise the user/agent won’t know who they are

<justin> WileyS, well, there's no "analytical purposes" permitted use, even in TCS :) But none at all for TPE, if you're retaining data at all, you need to say "T" and can provide information in WKR around what you use tracking data for.

… Nick, you changed a reference from “first party” to “that party”, which is actually quite a significant difference

<fielding> remember that tracking data is about a particular user across multiple sites

<WileyS> Justin - okay, as long as data in aggregated/de-identified we're good. I think that should cover us.

<Zakim> dsinger, you wanted to discuss a minor question

justin: moneill2, good if you can send some of that in email

<moneill2> ok

dsinger: why not just report any single tracking status response, not just N? could work for T as well, say

<WileyS> I don't believe any of the exchanges will be able to respond in that manner today - will take time - if it ever happens at all.

justin: +1

<moneill2> dsinger: missed it

dsinger: I’m not sure about how the gateway should respond about its own tracking

… what happens if the gateway has an exception, or the other sites don’t, or vice versa?

<moneill2> dsinger: gateway tracking - missed a load of that my phone died

<vincent> WileyS, if there are multiple recipients I'd like to know when information about me is collected/used by multiple parties

<WileyS> The gateway will only tracking for operational purposes: security, financial, and reporting - not profiling

fielding: the service provider requirement was to handle the gateway tracking issue

<WileyS> Vincent - doesn't the "G" response tell you that?

<justin> WileyS, right but that's still tracking for TPE

… in that case, you can’t do tracking other than just for the recipient that you’re a service provider for

<moneill2> fielding: service provider requirement ... my phone died again .

… if the user-granted exceptions apply to the particular request, to the entire exchange

<moneill2> can anybody else scribe my phone keeps fading out

<WileyS> Justin - I disagree, we should only have to respond with "T" if actual tracking is occurring, not only a permitted use

<WileyS> Justin - permitted uses are permitted uses for a reason

<moneill2> npdity: phew

<vincent> WileyS, if I have a G yes and that's ok with me. But if I have a N I'll guess that only one party received data about me and that's clearly not the case

fielding: transitive in the sense that the exchange can do with it what it wants, including with other parties

<justin> WileyS, there are no permitted uses in TPE. That's in TCS. In which case you respond T and link to TCS to explain the limitations on the tracking you're doing.

<WileyS> Vincent, I don't believe the "N" will realistically occur in the Gateway/Exchange scenario - not for a long time if at all

<Zakim> npdoty, you wanted to respond separately to mike’s question

fielding: other responses might inspire the user to ask for more information about the data collector, which is why I suggested that the only common response to send back is N

<WileyS> Justin, agreed - but "T" is only required when you meet the definition of tracking which the TCS states permitted uses are not considered tracking.

fielding: added requirements to make it more palatable, but if advocates feel it’s not useful, no objection to changing

<justin> WileyS, I think "permitted uses" are still technically tracking, they're just permissible tracking (as defined by TCS).

<moneill2> that party could be either party

<WileyS> Justin, I don't believe that's correct then - as we should only need to respond with "T" when actual cross-site tracking is occurring for a non-permitted use.

npdoty: on moneill2’s separate question, I didn’t intend to make a major change, was just trying to make smoother language. email me and I’ll fix it

justin: thanks fielding for putting this together

… there might be some questions that are challenging to deal with it

<fielding> T is for tracking, including for a permitted use. Tracking itself is only for cross-party data collection.

… let’s try to gather together on that

justin: I’ll follow up on the list today

action-465?

<trackbot> action-465 -- Roy Fielding to Respond to issue-260 regarding validating dnt signal -- due 2014-11-26 -- OPEN

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

fielding: didn’t get to it. <illness>

justin: fielding, any comments to nick’s proposed edits regarding yours, David’s and his language?

fielding: nick made additional edits which may have addressed my concerns

Compliance

http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html

<justin> scribenick: justin

npdoty: I've been making editorial changes to TCS, tried to document with comments.
... Two primary reasons: one was issue-203, how to use tracking in the TCS, how to indicate what you think you are, how to indicate compliance.
... Updated Section 3 on how to respond, and indications to other sections.
... Also updated scope and substantive section to make clear that what you're purporting to comply with is what you comply with.
... Also, made editorial changes just to clarify. Didn't try to change substance, but if you disagree, please let me know.
... Also updating scope section, lots of other proposals most of which are out of date. Tried to accomodate, lmk what you think.

<npdoty> scribenick: npdoty

justin: nick will continue to clean up Compliance doc

… hope to get to agreement on the particular issue-203

<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

… sounds like the hardest thing we have left to do is issue-262

… I think after 262 and 260, then I think we’re pretty close to done

fielding: suggest that we publish nick’s document as a Working Draft this week or next week

npdoty: did publish a Working Draft just before thanksgiving

dsinger: which process?

npdoty: following existing 2005 process. definitely good to ask for comments early

dsinger: good to reach out to stakeholders, maybe PING

<moneill2> webapps security

npdoty: still making editorial changes now, so might be better to do another snapshot and ask for a wider review in a week or two

justin: sounds reasonable, we still have TPE to work through

dsinger: an update on the JavaScript issues

… made those changes to the draft last night

… links to formal definitions, uncontroversial

… we decided to keep the cookie-processing model, as discussed

… move the status to navigator from window, we agreed

… can’t switch to an enumerator, since there are possible extensions, keep a string

… exposes in Service Workers now

… not returning a Promise from the exceptions calls, because these are synchronous from the point of the view of the page

… the site has already got consent

… only seems like an edge case

… changed the advisory note to regard to other visits

… sticking with URI instead of URL

… delete explanationString and siteName? just insert a note about how the UA presents them

<moneill2> yay, will do

… integrates Mike’s expiry parameters, I believe verbatim

<dsinger> http://lists.w3.org/Archives/Public/public-tracking/2014Dec/0016.html

… Mike, please check

… summarized in email

justin: thanks dsinger for working through all those

… everyone, please take a look at that

dsinger: does anything need to be marked at risk?

justin: concern about european regulatory requirements regarding marking expiry at risk

… think the group all came around to that, but send replies to the list as appropriate

dsinger: CR early next year?

justin: yeah

fielding: unless we think another last call is merited

npdoty: just to confirm, will we plan to talk on December 24 or 31?

<dsinger> looks like the editors should do a diff from the previous last-call document, but I don’t think anything we made major technical changes in TPE

<dsinger> suggest weekly calls until we get to LC on Compliance?

justin: no. and not clear we need regular weekly calls in January either, depending on when it’s needed

<fielding> I will be on vacation Dec 20 through Jan 4.

justin: will discuss with other chairs about how much time we need to take up going forward

… talk again next week

trackbot, end meeting

- DRAFT -

Tracking Protection Working Group Teleconference

10 Dec 2014

Attendees

Contents

TPE Last Call issues

Compliance

Summary of Action Items

Scribe.perl diagnostic output