See also: IRC log
<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.
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?
<trackbot> issue-203 -- Use of "tracking" in third-party compliance -- open
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_: we'll need a proposal about the 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.
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: 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?
justin_: anything else on this issue?
justin_: two more issues.
... 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
<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/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
... 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
justin_: somewhat similar to the
"yellow" approach shane proposed last summer in sunnyvale, I
... don't think that's likely to be merged with another proposal. Any questions?
... Ok. Last issue is personalization.
justin_: I grouped a bunch of issues together here.
<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
... 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.
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_: having the prohibition on frequency capping doesn't make sense?
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
... 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)
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.
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.
justin_: anything else?
... thank you Sid
... for lots of words
my fingers urt
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:[End of scribe.perl diagnostic output]