<npdoty> trackbot, start meeting

<trackbot> Date: 11 March 2015

<schunter> yes

<schunter> Should we get started or wait some more?

<walter> WileyS: a) there haven't been many calls lately and b) the number of open issues has dropped off no less significantly

<npd> scribenick: npdoty

schunter: long time since last call. progress made on edits in the meantime. almost ready to move documents to next steps.

TPE

schunter: last time Roy summarized edits for Last Call changes
... remaining changes that have been suggested
... copy definitions of service provider and permanently de-identified, although both only used once in TPE
... part of User-Granted Exceptions section that discusses transferrable exceptions
... no support for that directly in the protocol
... remove that from TPE now? possibly move to compliance if folks want it

<schunter> https://lists.w3.org/Archives/Public/public-tracking/2015Feb/0004.html

schunter: the only things I know that are left to do

<fielding> possibly copy definitions of service provider and permanently de-identified from TCS

<dsinger> I think it’s also the case that the ad-exchange works by redirect rather than proxy (that’s the unstated assumption in this). This section is quite old.

fielding: creating a re-direct on the page for a partner, already has a DNT:0 or exception

<walter> Does it belong in the spec then?

(not-scribe), dsinger, right, this would only apply for redirection cases. server-to-server is better handled by G or C tracking status values

fielding: this indicates that a server would respond with C, to claim transferred consent, but the consent wouldn't have been with the user directly
... and we haven't defined a qualifier "t" in our compliance document

<Zakim> dsinger, you wanted to try to explain…

<WileyS> Very common case for intra-Ad Network and Ad Exchange calls

dsinger: a server that has consent and re-direct and say, I'm still tracking you because I have a transferred consent

<dsinger> I think that AdPartyA gets a direct request and has Consent, either in-band DNT:0 or out of band. It redirects to B, and has a contract with B, and B serves the Ad under the terms of that contract.

<moneill2> +q

schunter: you're saying ad exchanges don't work in that way?

<dsinger> history here in my response https://lists.w3.org/Archives/Public/public-tracking/2015Feb/0005.html

fielding: no doubt that there are some cases. but is it good in that case for the response to be "consent"
... if it's not quite consent, then the response should be considered dynamic

<walter> Can the FTC folks look for their mute button?

fielding: qualifier "t" wouldn't add value to the user beyond getting consent

<WileyS> So it will appear to the browser that the party has OBC

dsinger: the user may be surprised to see consent for Party B; there could be an indication that they're working for someone who did receive consent

<WileyS> The browser doesn't need to know

dsinger: the user and user agent between them would have to decide

<WileyS> For OBC, the browser wouldn't have context so I'm not sure how this is different

<dsinger> right, for OOBC it’s the user who would know. the UA does not

schunter: if you have a privacy-mode in browser that inspects the status values for all the sites, might be flagged
... the transferred would give an indication that it got it from somewhere

<dsinger> so, between the UA’s record of exceptions and the user’s memory of OOB consent grants, neither can work out why B claims consent

<WileyS> So the Service Provider will need some way to communicate to the user that they are operating another party's consent

https://lists.w3.org/Archives/Public/public-tracking/2015Feb/0011.html

<fielding> to be clear, just removing the section makes no technical changes because the server is still going to respond with C in that case,

<WileyS> Is it useful? It depends on what web browsers do in this case. If they raise warning alarms then we'll need some way to communicate to the user that this is an appropriate behavior

<WileyS> Hard for us to say now if this will or will not be useful

npdoty: +1, can remove section and servers will indicate C if they believe they have consent. we can have a "t" qualifier if implementers would find it useful

<dsinger> yes, it’s clear they say C as their main status. the only question is explaining how they claim consent (‘acting for another party who has consent’)

(not scribe) WileyS, in that case, maybe we should leave "t" out until we see that it's an issue

<fielding> or simply move this section to TCS

moneill2: "C" would certainly cover it. just whether we need an additional granularity, don't know. could mark "at risk"

hearing options: (1) mark "t" at risk in TCS; (2) remove altogether

<dsinger> why don’t we take the ’t’ out and add a note saying that “it may not be clear to the user why the party claims consent, and in that case, a qualifier might be needed”? this is the sort of thing one finds out in practice

<walter> Ok

<walter> sorry

<walter> can I write on the channel?

<walter> instead

<schunter> sure

<walter> My point is, this is already covered by same-party flag

<walter> As far as I understand the use case mentioned by WileyS

<dsinger> suggest: move to TCS, remove ’t’, add a note explaining the question

<walter> Or at least, same-party can be used to achieve the same thing

fielding: same thing can be said in TCS without indicating a qualifier

<fielding> or the "t" signal can be properly defined in TCS

schunter: would like to have explanation of how the protocol is used to be in the TPE

<dsinger> suggestion 2: move to TCS, keep the qualifier, add it to the qualifier section

npdoty: move to Compliance, give a qualifier, if necessary

<moneill2> ok

npdoty: keep the "t" qualifier and mark as risk? or drop it for now and wait and see if we need it?

schunter: reluctant to make larger edits in TPE. in TCS, we could have another round of public scrutiny

<scribe> ACTION: doty to move "transfer" concept/qualifier to TCS [recorded in http://www.w3.org/2015/03/11-dnt-irc]

<trackbot> Created ACTION-466 - Move "transfer" concept/qualifier to tcs [on Nick Doty - due 2015-03-18].

schunter: one feature marked "at risk"

fielding: yes.
... and a reminder that we use "service provider" and "permanently de-identified" used in one place each
... easy solution is to copy those definitions, but we can deal with it

npdoty: in responding to Last Call commenters
... I've followed up with i18n
... dsinger, can you follow up with Anne?

schunter: can we point just to spec?

npdoty: polite to send a link to the Tracker
... need to make a group decision to go to CR

fielding: wait until final edits, then send an email with a request to the group

message to the group to come from the chairs

Compliance

https://lists.w3.org/Archives/Public/public-tracking/2015Mar/0000.html

and a thread following on that

<ws> scribenick: wseltzer

npdoty: comments from Roy and from Mike
... most useful woudl be to figure out where we disagree

fielding: most of my comments were editorial

<npdoty> https://lists.w3.org/Archives/Public/public-tracking/2015Mar/0002.html from Mike

moneill2: disagreed with tracking data removal; it has a meaning
... the piece of data which allows you to be tracked
... some example text
... Example 2, I don't think is clear
... unclear whether it's in permitted use or outside

schunter: I'll ask Roy to make editorial edits
... and send dsicussion emails to the list where you believe we need discusion
... do a round of discussion on the list where there's disagreement

<fielding> well, this is TCS -- do you want me to edit it?

schunter: Mike, please point out things that are more than editorial

npdoty: we already have one such disagreement, re "tracking data"
... I'd normally do the editorial edits

fielding: do you want Nick to do the edits to TCS?

npdoty: I'll do the first pass

fielding: I can look again at where "tracking data" is use d in the 2 specs
... I know it doesn't mean UIDs in the TPE
... We're talking about making the requirements narrower, rather than broader
... don't know why we'd want to do that.

npdoty: situation where I've collected info in only one context; can I share it anywhere?
... it may not yet be "tracking," but it could be used for tracking

moneill2: deidentified def also uses "tracking data"

npdoty: pointer?

moneill2: I'll extract in a couple of emails to the list

schunter: we'll make the clearly editorial edits and that shoudl bring us closer to last call

<fielding> it is clearly not used in that way for the definition of de-identified

npdoty: process. we might be ready to ask people to do last reviews
... or make the last edits, and do it in email

schunter: wait until it's stable to call for review
... AOB?
... by next week, Mike should ahve sent email, so we can meet next week. we'll discuss

<vincent> just a quick question about the timeline

<npdoty> yes, I'm ready to get these out the door

<schunter> vincent? Any final words?

<npdoty> vincent, are you calling back in? or can you type in IRC?

<vincent> will do in irc

<vincent> sorry what would be the timetable to provide review cause article 29 won't be able to provide a feedback before late june , would that be ok?

<schunter> We can discuss this next week.

<vincent> (sorry my phone battery is dead)

<vincent> sure

<fielding> also, the section on No Personalization in permitted uses clearly intends "tracking data" to be all data collected as a result of tracking.

schunter: Likely to ahve a call next week

<moneill2> bye

[adjourned]

<vincent> bye and thanks to the scribes