<trackbot> Date: 23 July 2014

<npdoty> scribenick: sidstamm

<Chris_M> just joined the call

justin_: calls for objections.. one we reached decision, another is hard to make decision
... on the limitations on first parties (data append) proposal to add language
... chairs decided stronger objections were against adding that language, since it goes beyond def'n of tracking
... second one was on context separation. Can big first party use it when acting as a third party?
... there were related issues around personalization that need to be addressed first
... second issue that made it hard was specifically around first vs third party
... that kind of ties into today's first issue, the use of "Tracking" in compliance
... fielding suggested maybe we don't need separate rules for first/third parties, indicating maybe we just shouldn't blend any contexts
... was challenging for the chairs to assess rules based on 1st and 3rd party
... so we are delaying the result of that until issue 203 and personalization issues are addressed.

issue-203 use of tracking in compliance

justin_: On issue 203, question for fielding, have you had the chance to look at what new compliance rules would look like?

fielding: haven't written yet, would you like me to write first?

<dsinger> issue-203?

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

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

justin_: yes, please write.

<npdoty> I made edits yesterday (action-454, regarding qualifiers) but haven't completed what we suggested I do with tracking status values (action-455)

justin_: last week some folks were concerned about what it looks like, so text would be helpful.

<justin_> https://www.w3.org/wiki/Privacy/TPWG/Change_Proposal_Tracking_Third_Party_Compliance

justin_: we'll need a proposal about the qualifiers

<npdoty> http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html#qualifiers

justin_: nick, did you get the qualifiers ported?

npdoty: yep, see link
... but that doesn't cover when to use the status values
... still working on that

justin_: who will do it?

npdoty: I will get to it

justin_: I'll encourage folks to look at the new qualifiers language
... and when npdoty provides the rest of his text, look at that too
... once we have more about context, there will be more to discuss
... Any questions about all that?

<npdoty> dsinger, did you have any updates on possible merging of yours and fielding's text?

justin_: Ok. Will wait to see the new text from fielding/npdoty. May impact on the structure of the document, but may or may not have impact on individual companies. HOpefully will discuss next week.
... next issue is link shorteners.

issue-97 link shortening

<justin_> https://www.w3.org/wiki/Privacy/TPWG/Change_Proposals_on_link_shorteners_and_ID_providers

justin_: scheduled to go for CFE today on link shorteners

<dsinger> to npdoty: on which issue? issue-188 is still going in side emails

<npdoty> dsinger, I meant on issue 203 (use of "tracking")

justin_: rift in the group about whether link shortners are first or third party
... walter/nick worked on various iterations of language including some explanation about party-ness of link shorteners
... walter wanted more time, so just as an update, they're going to come up with a final concrete proposal (probably not mentioning parties)
... and when that gets finalized, we'll bring to the group for CFE.

<dsinger> to npdoty: no update right now

npdoty: is there a rift? I haven't seen other proposals
... if we are wordsmithing, no problem, but if not we should get it on the wiki

justin_: I think at least shane has objected and said the service provider should not be considered a party to that transaction

<WileyS> On the grounds that a user has full view of the link prior to interaction.

<WileyS> Same standard we set for widgets

<WileyS> And for 1st parties generally

justin_: and I think there have been others who objected to that perspective

<WileyS> +q

WileyS: my proposal is that we don't speak to this
... multiple parties stated the same thing. this group should remain silent on this topic

<npdoty> okay, I hadn't realized the suggestion was separate silence, I'll add that to the wiki

WileyS: instead of attempting to add normative or nonnorm text on this
... when we look at principles of user knowledge/discoverability/interaction, we take the position that if the user has the ability to understand what they're doing
... then it's a first party interaction
... if they see a link shortner and click on it, they know they're interacting with the link shortening service
... the more core elements we started with were the invisible third parties
... and my proposal is non-text.

<npdoty> thanks, I'll add to the wiki

justin_: and you think the existing text is sufficent for invisible redirectors?

WileyS: yep

justin_: anything else on this issue?

<justin_> https://www.w3.org/wiki/Privacy/TPWG/Change_Proposal_Deidentification

justin_: two more issues. De-identification, first.
... operative proposals (4)

<npdoty> WileyS, added quickly here: https://www.w3.org/wiki/Privacy/TPWG/Change_Proposals_on_link_shorteners_and_ID_providers#Proposal_5:_Silence feel free to correct/update

justin_: three part test
... from david.
... roy's takes away contractual stuff (?)
... I think roy had a good point that if you publicize data and it's clearly de-identified
... no way you can get everyone to agree to not re-identify it

issue-188 deidentification

<dsinger> You can surely say “this data is made available under the condition it not be used to identify…”

justin_: can we remove that, david?
... david/roy, want to take up now?

dsinger: maybe we can say this is a characteristic about de-identified data
... maybe it should be made available on the condition you don't try to identify people in it
... rather than a contract, maybe the characteristic of the data is that restriction.

justin_: would that mean there's a legal disclaimer on all released data?

dsinger: you would probably put that somewhere

<Zakim> npdoty, you wanted to ask about aggregate vs. de-identified

npdoty: if the case in question is where you aggregate a large number of records
... then it can be made public without an agreement, because there's no risk
... should we instead say either "aggregate the data or put on the disclaimer"?

justin_: two part test, right? For stuff you're pretty sure can't be re-identified, you are ok, but wouldn't hurt to add legal protection with the condition

<dsinger> we could say that the publisher either accepts responsbility for any re-identification, or prohibits it

justin_: but for stuff you're sure about, you wouldn't have to put it in place. not sure if feasible.

<npdoty> define "aggregate" as separate from "deidentified" (which could follow an FTC-style test, which many of the proposals follow)

dsinger: maybe either you accept responsibility or you prohibit it.
... if you're completely confident, there's no reason for the restriction

fielding: only issue is that if we truly de-identify data, it should be impossible to re-identify
... so this concern is understandable if we don't de-identify right

dsinger: long history of people thinking it's de-identified, but were wrong

<npdoty> "reasonable level of justified confidence" (current text) isn't the same as "impossible"

dsinger: so we should add the condition that others *can't* reidentify

fielding: so we're saying "this has to be impossible and a contract in place"?

<JackHobaugh> seems like we are mixing de-identification with anonymization

dsinger: no, you have to _think_ it's impossible and add a safety net condition

<npdoty> I think that's driven by a history of people being incorrect when they believe data to be de-identified

justin_: high level of confidence plus policy protection, right?

dsinger: the situation I want to avoid is that someone makes the data available, disclaims all responsibility, someone else de-identifies it, and they collude to get around these guidelines

<npdoty> JackHobaugh, I think we've tended not to use "anonymous" because of lots of previous misapplications of the term. but I think "aggregate" might actually be the relevant term here

justin_: if they release that data you would say there would be a proof burden, but not sure it's much worse than just secret data transfer

fielding: if it said "cannot be released except under contract or if data is truly anaonymous"... then we have to define "anonymous"

dsinger: that's why I was leaning towards just requiring someone to accept or pass-on responsibility

justin_: even if you're "winking", you still have responsibility, right?
... maybe we take this to the list and iron it out.

dsinger: I'll try to phrase something along the lines of what I'm thinking.
... not sure if it'll fly with everybody, but I'd like to try.

<npdoty> FTC folks on the phone, any interest in speaking about your de-identification approach and aggregation?

justin_: those are two. vincent had proposed language on the article 29 def'n.

vincent: I think I had responded to most of the questions
... while there are technical guarantees that it is not identifiable, we would not need to require contracts. But the idea was trying to provide some guarantee that you wouldn't be able to re-identify the data
... to help with assesment

justin_: to add extra parameters since re-identification isn't particularly knowable.
... maybe this can be worked on the list
... or maybe this is an effect of two legal regimes with two sets of requirements
... or maybe there's no way around that
... will legal regimes trump here anyway?

vincent: I want to provide smaller granularity on the requirements

justin_: roy's saying "make sure it's deidentified" and you're adding "how", right?
... different ways to approach it
... not trying to say which is better but I don't think we're going to work it out in this call
... lets keep talking on the list?
... Last we have the proposal from JackHobaugh from NAI

<npdoty> both JackHobaugh and vincent are proposing different substantive requirements to define when something is really de-identified (based on HIPAA or Art. 29), right?

justin_: more long and detailed and somewhat mirrorred in HIPPA's approach, saying you can subtract out certain elements and that's good enough

<npdoty> https://www.w3.org/wiki/Privacy/TPWG/Change_Proposal_Deidentification#Expert_review_or_safe_harbor

justin_: somewhat similar to the "yellow" approach shane proposed last summer in sunnyvale, I think
... don't think that's likely to be merged with another proposal. Any questions?
... Ok. Last issue is personalization.

issue-234 personalization

justin_: I grouped a bunch of issues together here.

<justin_> https://www.w3.org/wiki/Privacy/TPWG/Change_Proposal_Remove_personalization_prohibition

<vincent> npdoty, from what I understand, the def I propose is jsut a possible solution to meet the requirement of Roy's definition

justin_: one of the ideas that came out last summer was the idea that (interrupt me if I'm wrong) there's a sense that we can't control the DNT signal and there's no way to verify it
... so maybe we aren't prepared to turn off all behavioral advertising when DNT is on and maybe instead we should do some sort of middleground (clense URLs or do data hygene) but some level of targeting should be allowed
... in oct when we were asking for language suggestions, we got a bunch
... Jack proposed a few around this issue that DNT should not turn off behavioral.

<Chris_M> As I remember, this was actually first proposed by Jonathan Mayer... DNT does not = do not personalize

justin_: There's a general permitted use saying you can't personalize apart from some specifics
... david wainberg also proposed some things should be allowed
... Jack proposed something about maintaining history, but keep audience segments and can use the URL for permitted uses (?)
... one thing to talk about is removing profiling from frequency capping?

<JackHobaugh> Justin, I think your summary is correct.

<npdoty> regarding 236: https://www.w3.org/wiki/Privacy/TPWG/Change_Proposal_Remove_profiling_prohibition_for_frequency_capping

Unfortunatly the scribe didn't capture all that, sorry

<npdoty> regarding 234: https://www.w3.org/wiki/Privacy/TPWG/Change_Proposal_Remove_personalization_prohibition

<npdoty> the scribe's best effort is appreciated.

JackHobaugh: permitted uses and profiling are not exactly non-overlapping circles, may not be accurate when taking in the document as a whole

<justin_> http://www.w3.org/2011/tracking-protection/track/issues/236

justin_: having the prohibition on frequency capping doesn't make sense?

JackHobaugh: yes

npdoty: I am trying to get clarification from jack if his proposals are just editorial or if we should have a new set of requirements

JackHobaugh: I was suggesting it doesn't fit in "frequency capping", if it needs to be addressed
... but many of these issues are connected.
... if you're in an area talking about permissions, you shouldn't attack it from a prohibition side also

justin_: that's helpful. Looking at the language on freq capping

<npdoty> I believe the thinking was that there may be certain requirements in order to fit into a permission

justin_: Generally, you can still collect for frequency capping but must not construct profiles or alter user experience
... So you're not allowed to log for profiling, but can do contextual ads.
... idea is that if you can infer based on ads you show, you shouldn't be creating meta-profiles based on this inferred data (from freq capping)
... but the general prohibition on personalization would address it. But if some is allowed, that's inconsistent with the rest of the doc.
... not sure why that language was there in the first place.
... this was controversial when initially proposed last summer, but lots of folks think we need to consider it.
... Are there other issues we should loop in with this?

<npdoty> I thought maybe 236 was just a suggestion to rely on the "No Personalization" general requirement rather than permitted use by permitted use, but 234 also suggests that we drop the general requirement section

justin_: if folks want to suggest refinements or new language, go ahead. I will go to list with specific sentence cutting.

<Zakim> dsinger, you wanted to mention in-context actions

dsinger: We shouldn't worry about use of data in a transaction. That's not tracking.
... tracking is about recording, not reacting to data in the transaction.

justin_: I think we all agree about that.

dsinger: personalization based on the fact that you're using Firefox and your IP says California, that has nothing to do with this.

justin_: but remembering it later may be in scope.
... I don't think there are disputes on that.
... ok. So I think that's it for today.
... lets try to keep working on de-identification. David just put something to the list.

<WileyS> There is a more fundamental question as to the scope of DNT. If the scope was limited to the historical retention of cross-site data (different contexts), then scoring could still occur (prior to de-identification).

justin_: if we can come up with fewer alternatives, the better.
... want to see what roy/david can come up with about how tracking is used (wrt parties)

aob

justin_: one other issue is that we are required by W3C policy to submit working draft
... we should wait until the context issue is ironed out before doing a snapshot. Nick?

npdoty: we're required to do it every three months. Our due date is in a couple of weeks.
... if it's gonna take longer, that should just go to the next WD.

<fielding> I can do a couple weeks (for TPE)

justin_: maybe we can put a pointer in the doc saying we're working on this.
... I don't mind publishing with that caveat.
... objections?

npdoty: I'll add a note highlighting that issue and send it around looking for concerns about publishing.

justin_: thanks. And thanks roy for committing to quick turnaround.

<npdoty> thanks

justin_: anything else?
... thank you Sid
... for lots of words

my fingers urt

scribe: bye!

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/?:/JackHobaugh:/
Found ScribeNick: sidstamm
Inferring Scribes: sidstamm
Default Present: npdoty, dsinger, [FTC], Fielding, hefferjr, WileyS, Jack_Hobaugh, vincent, +1.646.654.aaaa, sidstamm, eberkower, WaltMichel, kulick, justin, moneill2, Chris_Pedigo, Chris_M, Brooks, adrianba, Jeff, robsherman
Present: npdoty dsinger [FTC] Fielding hefferjr WileyS Jack_Hobaugh vincent +1.646.654.aaaa sidstamm eberkower WaltMichel kulick justin moneill2 Chris_Pedigo Chris_M Brooks adrianba Jeff robsherman
Regrets: wseltzer
Found Date: 23 Jul 2014
Guessing minutes URL: http://www.w3.org/2014/07/23-dnt-minutes.html
People with action items: