See also: IRC log
<trackbot> Date: 29 May 2013
<eberkower> aabb is eberkower
<jchester2> hello privacy campers!
<Chris_IAB> just joined
<peterswire> 202.587 is peter and yianni
<Chris_IAB> npdoty, yes
<npdoty> scribenick: Yianni
Peter: we are getting
... agenda for call: number of action items
... discuss additional activities around consensus action summary
... clarify pending review stable
... like to thank Nick to clean up open aciton items
... in terms of items that have received a lot of back and forth: one of them is action 410
... Walter and Rob have written about
... Walter are you on the call?
... Rob are you on the call?
... thank you Rob for your comments
... Rob could you describe the issue and your understanding
Rob: disagreement with Walter,
the issue may not be covering his concerns
... at the moment, it is not a real big issue
... agree with what Roy has said so far
Peter: Moving issue to closed,
Roy did not support any language
... anyone to speak against closing the issue
... we will recirculate intent to close
... we will close issue 184 and action 410
... action 406, new set of names around the yellow state
... red, yellow, green has some advantages
... goal to be understandable, not making any legal judgment, and if we use words used elsewhere, we need to be thoughtful, such as de-identified
<trackbot> ACTION-406 -- Rob van Eijk to porpose a new set of names around yellow state -- due 2013-05-29 -- OPEN
<WileyS> We should also try to avoid technology specific terms, such as "hashed", and focus on principles
Peter: Rob in addition to substantive questions, where are we in naming
Rob: Shane and I have basic
disagreement, on role of administrative safeguards
... unlinkability is about adding new data
<WileyS> Tech + Operational + Administrative can equal "de-identified" (unlinkablity is different and must stand on its own)
Rob: identifiability is different
from unlinkability, taking account of all means to identify a
... important to get language right
<rigo> RE: identifiability is not linkability. linkability is the possibility to add new data to an existing profile
Rob: FTC and NAI notion of
de-identification is a process, start with looking at raw
... first step consists of taking out directly identifiable elements, email address
... second step, partially de-identified level
<WileyS> Important to note "reasonably identifiable" in the EU context
Rob: not reasonable linked, need
to take extra effort t otake out indirect identifiers
... to accomplish full de-identified process, i have proposed a three state model
<jchester2> This is a very important proposal, and we thank Rob for this.
Rob: raw data, to get from raw
data to yellow or de-identified, you need data scrubbing
... to get to full de-identified, you need to do something else
<WileyS> Yahoo! has been using a tri-state deidentification process for nearly 7 years - heavily reviewed with DPAs and A29WP
Rob: de-identification is a way
to look at end result, how difficult is it for a party to
identify to a user or device
... a hahed pseudonym could make it very difficult
<jchester2> Shane: So what Yahoo is using to target users, such as with Genome, is all Yellow?
Rob: it is a way to address
reasonable requirements of adequate level of protection
... an adequate level of data proteciton is different from concept of unlinkability
... Rob will post in IRC
<WileyS> Jeff - no, that data is the raw state for non-opted-out users (but the raw events are scored and only the score remains for targeting - not the event level data)
Rob: main difficulty is to determine that data that has gone through first step of de-identificaiton under strong assumption of organization safeguards is that enough to count as full de-identification
Peter: how do we describe these
<rvaneijk> PII: This standard refers to the ISO 29100 (privacy framework) definition of personally identifiable information (PII): any information that (a) can be used to identify the PII principal to whom such information relates, or (b) is or might be directly or indirectly linked to a PII principal. NOTE To determine whether a PII principal is identifiable, account should be taken of all the means which can reasonably be used by the privacy stakeholder holding the[CUT]
<npdoty> is the difference that Shane and Rob disagree on the use of organizational safeguards between red and yellow state or between yellow and green state?
Peter: we have long standing
concern of technical or administrative measures
... have a question about naming
<jchester2> But it also must be discussed in terms of what it may mean for a meaningful DNT standard.
Peter: first step, take out
... second step, take out indirectly idenfifiers
<efelten> What's the dividing line between "direct" and "non-direct" identifiers?
Peter: first, not directly identifiable
Peter: second, not indirectly identifiable
<WileyS> "reasonable" is important
Peter: could put reasonably in
... direct identifiers have an intuitive meaning, Peters name in it
<jchester2> Peter: Why can't we use the sample color labels, which a user can better understand?
Peter: offer that as a thought or suggestion
Mike Oneil: differences between unlinkability and de-identified is not just about direct and indirect
<WileyS> I'm fine with "not directly identifiable" (aka de-identified) and "not indirectly identifiable" (aka unlinkable)
scribe: if data point from same person can be linked
<efelten> If we are going to distinguish between "direct" and "indirect" we need to define what the difference is. Not enough to just give a few examples.
scribe: with yellow, there is the potential about being re-identified
Peter: 2 different tasks, one
what do we name the state?
... second task, is it good enough to fit into the state
Rigo: I think we have several
functions, I wanted us to think in functions
... the names we use are replacements for functions we have
... if I have a profile without a name but can single out that person in anyway, I can still distriminate against that person
<WileyS> Potential, or risk, is a core element of the middle state - organizations are committing to not re-identify (and bolstering this with technical, operational, and administrative controls). This is an "accountability" based approach. Very similar to many other organizational committments to users.
Rigo: data protection function,
and goal of what we do here, because people are discriminated
because they are singled out
... if we go to yellow, we need at least a pool of 50 people
<Chris_IAB> wait, who's discriminating?
Rigo: not too much of a controversy about it
Peter: does that inform your view on the naming?
<WileyS> Rigo, no issues there - please provide wording to match the concern.
<ninjamarnau> Thanks Rigo. "singling out" is the important issue imo.
Rigo: shouldn't care too much about the name, just do not want to allow discrimination
Peter: name can confuse or lead to assumptions
Ed Felten: if we are relying on a difference between direct or indirect, we need a technical definition
scribe: very difficult line to draw
<WileyS> Ninja and Rigo - your callout is well aligned with the intentions of the tri-state proposal
Peter: one problem with label is
that any labels will have difficult line drawing
... are there better summary terms
Rob: one response to Rigo, we
should first try to get 3 stages rights, then we have a
foundation to build on, what permitted uses are allowed in what
... second, linkability is the key element, the second element is data retention
<rigo> WileyS, Rob, ok, not interfering too much with your plan to tackle one thing at a time
<rvaneijk> first get the 3 states right it allows to have a discuuion about the permitted uses Linkability is key Data retention
Jeff Chester: I don't see a distinction, you do not need a name, it is direct not indirect at all
<rigo> WileyS: what is the current location in the Spec for that wording?
scribe: agree with Rob, that if we get this right, we can move forward
<npdoty> jchester: a persistent identifier can be used for targeting
scribe: personally like the red, yellow, green
<WileyS> Rob - correct me if I'm wrong, but I believe we agree on the states and the process, and only disagree on naming. Fair?
<WileyS> Jeff, once a record has been made "not directly identifiable" then it can no longer be used for targeting.
<ninjamarnau> WileyS, I do not mind the tri-state. My concerns are about the measures and requirements in the yellow state. whatever we call this state.
Rob: differeneces between getting to one state or another, describing state is in terms of requirements
Mike Oneil: getting to one word is the problem, yellow state is de-id but still linked, green state is unlinked
scribe: we should use both linked and unlinked, de-identified and identified
<WileyS> Ninja - that's fair. The goal of the yellow state is force this data to only be used for analytical purposes - no active use in production situations (profiling, targeting, etc.).
Peter: action item for 2 weeks,
Peter would write up, glad to help, directly and indirectly
... other proposals red, yellow, green, jeff supporting
... Jeff would you write up an action item text describing names for that
<Chris_IAB> peterswire, npdoty, many (most) of us from industry won't be able to make next week's call due to a DAA event
<WileyS> I'm fine with pictorially displaying red, yellow, green but I think we need more meaningful terms for policy discussions.
Peter: trying to get text generated, understand problem of drawing lines between the two
<jchester2> What does Rob plan to do on the states?
Peter: open to other language
... I will provide direct and indirect language
<npdoty> ACTION: swire to draft directly/indirectly -identified language proposal [recorded in http://www.w3.org/2013/05/29-dnt-minutes.html#action01]
<trackbot> Created ACTION-412 - Draft directly/indirectly -identified language proposal [on Peter Swire - due 2013-06-05].
Peter: Mike you said several pieces, if you have other naming approaches, we will look at in two weeks
<npdoty> action-412 due 06-10
<trackbot> Set ACTION-412 Draft directly/indirectly -identified language proposal due date to 06-10.
Peter: Jeff Chester action 411 on issue 10
Jeff Chester: we have nothing to say, I think at this point we have to let it pass
Peter: we will move to pending
... shift to pending review stable
<npdoty> item would still be pending review (so keep reviewing it!), not closed.
Recognizing the interdependence of many issues within the compliance spec, we are introducing a new issue category “Pending Review Stable.” The category will fall between “Pending Review” and “Closed.” “Pending Review Stable” means that discussions of the issue will cease until other issues are stable. When the Editors decide to add proposed text to the Tracking Compliance and Scope, the issue will move from open to pending review. When the [CUT]
Peter: this is language we circulated to group some time ago
<npdoty> note for nick: move ISSUE 10 to Pending Review Stable, with note
Peter: we are trying to clean up
action items and merge issues when possible, so website will
accurately show we things are at today
... that will allow us to focus on remaining items
... idea of pending review stable is interdependence of many issues
<npdoty> [CONTINUED] When the Chairs decide the text is stable, a note will be added to the issue-tracker stating the issue is “Pending Review Stable.” There could potentially be multiple stable options when the Chairs decide an issue is “Pending Review Stable.” Discussion of an issue in “Pending Review Stable” can re-start if there is a new proposal that gains significant support.
Peter: 5 or 6 interrelated
issues, hard to finalize until they know how different sets of
issues fit together
... there would still be pending review, and pending review stable would not be closed
<scribe> ...pending review stable is that discussion of issues would cease until we could look at whole package
<jchester2> Jonathan. Do you have any comments on action 411, issue 10. We just allowed it to move to pending review before you joined call.
UNKNOWN_SPEAKER: if Editors add
proposed text it goes from open to pending review, then when
language is stable, we will add a note of pending review
... we do not expect to discuss a pending review stable unless a new proposal is made with substantial support
... hope would be if we have lots of issues in pending review stable, we could look at things in a whole package
... going back to action item lists, we have other actions scheduled to be done by this date
<trackbot> ACTION-402 -- Shane Wiley to work with Dan to follow up on defining the "yellow" to "green" transaction with strong enough measures -- due 2013-05-28 -- OPEN
<rvaneijk> Yianni, I put the notes on the mailinglist, it is too big to past in IRC.
UNKNOWN_SPEAKER: action 402 - shane and dan, three states
Shane: we take language of Dan as is, we will be adding a few additional non-normative examples that do not go to as strong a technical measure to meet end point
Shane: the question is moving from red to yellow, from raw to not directly identifiable
<johnsimpson> apologies for joining late
Shane: we will need new language for next week
Peter: extend new language until two weeks
<npdoty> action-402 due 06-10
<trackbot> Set ACTION-402 Work with Dan to follow up on defining the "yellow" to "green" transaction with strong enough measures due date to 06-10.
Shane: we have plan to assemble language, just need to get the language in fron of Dan
<jchester2> I apologize. Have to go testify at USTR on data protection issues.
<trackbot> ACTION-403 -- Justin Brookman to write language on red / yellow / green -- due 2013-05-15 -- OPEN
Peter: on action list, Shane had 402, Justin is assigned to 403
<rvaneijk> Yianni: URL is here http://lists.w3.org/Archives/Public/public-tracking/2013May/0135.html
Shane: Justin has a mission with respect to 403 for him to resolve
Peter: could you coordinate with Justin
<npdoty> justin may have a separate issue with red-yellow-green, so will maintain his own action
Shane: Justin has a very unique concern, maybe more appropriate for Dan to work with Justin, they have same concern
<rigo> WileyS: Justin added this action-403 for himself to have a specific angle on the question of red/yellow/green and suggest to wait until he gets back. Suggest to add Dan to it as he may have same concerns
Peter: rigo any update on audience measurement
Rigo: Susan will go back to Jeff
Chester where we will figure out what the issues are to try to
get a better understanding
... tricky issue is common understanding of what we are talking about
... after this call, I will have a call with Susan
Rob: in the text Rigo and Susan
are working on, the data is not applied to individual, audience
attribution is not what we are dealing with
... I am worried about the application of the data to the individual
Rigo: I know about concern, Susan
said this is not what we are talking about
... audience attribution is not what we are talking about
Ronan.. make sure Neilson is included in audience measurement discussion
<npdoty> rigo and susan, can you CC Ronan on email thread?
Rigo: whatever we do will be in full and open scrutiny
Peter: RIchard you wanted to keep action 370 open
<trackbot> ACTION-370 -- Richard Weaver to propose narrower "market research" use (with David Stark, Justin, Susan, Ronan, Rachel, Chris_M, EBerkower) -- due 2013-02-27 -- CLOSED
Peter: would you be comfortable
closing action 370, for narrowing audience measurement
... if audience measurement is in another action item, we are okay with closing
<trackbot> ACTION-404 -- Susan Israel to further Fact finding on scope of audience measurement and the DAA exception (one page of text) -- due 2013-05-29 -- OPEN
Richard: we want to make sure that we are clearlly talking about audience measurement and not market research
Peter: we will not close action 370
Nick: on action 370, we will
leave action item open if you want to add proposed text
... we have an issue open, we only keep an action open if someone plans to take an action
Richard: we just don't want to close the door
<npdoty> sounds good, will follow up offline
Peter: next one on list is action 407
<npdoty> action-370: don't want the issue to drop, as ESOMAR folks may be interested in a refined proposal based on what comes up
<trackbot> Notes added to ACTION-370 Propose narrower "market research" use (with David Stark, Justin, Susan, Ronan, Rachel, Chris_M, EBerkower).
Peter: text around browser education
Chris: Alan and I have not had a
chance to work on,
... requesting an extra week
Peter: have that action due two
weeks from now
... David on for action 408
<npdoty> action-407 due 06-10
<trackbot> Set ACTION-407 (with Alan Chapell) to draft text regarding browser education as discussed in Sunnyvale (Item 6 in Draft Framework, also in consensus action summary) due date to 06-10.
David: waiting for feedback
<npdoty> action-408 due 06-10
<trackbot> Set ACTION-408 Review security/fraud text (with chris mejia and dan auerbach) due date to 06-10.
Peter: assign for two weeks
Nick: lost about other action, will do action 409 later today
<npdoty> action-409: Nick will update today
<trackbot> Notes added to ACTION-409 Circulate (with yianni, tlr, peter) regarding "graduated response" and old actions.
Peter: completes list of action items
Peter: next thing on agenda is
additional items on consensus action summary
... there will be a call on data retention
... other issues are audience measurement
... any other things we should be assigning on item 2 of action summary
... the other issues, meaning of de-id have been discussed today, we have gone through procedural issues of pending review stable
<trackbot> ISSUE-31 -- Minimization -- to what extent will minimization be required for use of a particular exemption? (conditional exemptions) -- open
<npdoty> jmayer, I think you had a concern on minimization and how to handle it as an issue?
Peter: minimization language is an open issue
<npdoty> I think that the draft has relatively stable text on minimization and general requirements: http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance#permitted-use-requirements
Peter: the idea here would be a follow up seperate issue on data retention
Rigo: I think there are distinct
... Ian Fette had an issue of even being exposed to data that you didn't want before you could clean them up
... he talked about an issue of short retention
... we do not consider this controversal, this is issue 31
<fielding> my only concern with that text is the last word "unlinkable"
Rigo: data minimization is critical to Rob, reason to collect and retain data
<npdoty> fielding, we would certainly want to update it based on updated definitions throughout the document
Peter: Rigo do you a suggestion of how to list this
Rigo: would suggest to close issue 31, after hearing from Rob and Shane
Rob: data retention is something
connected to each permitted use, might be different data
retention for each permitted use
... is data retention tied to any other issues?
<trackbot> ISSUE-134 -- Would we additionally permit logs that are retained for a short enough period? -- open
<npdoty> in terms of short-term retention of logs, that's consolidated into issue-134
Peter: follow up with Thomas
about short term retention is not lost
... if it is part of broader discussion then it will go into that
... last item I have on the list is a question of keeping issue 188 and 191 to deal with de-identification
<trackbot> ISSUE-188 -- Definition of de-identified (or previously, unlinkable) data -- open
Peter: seperate issue for normative text and for non-normative text
<trackbot> ISSUE-191 -- Non-normative Discussion of De-Identification -- raised
<rigo> suggestion is to note in ISSUE-31 that it is superseded by ISSUE-134
Peter: Jonathan Mayer asked to keep the issues seperate
Jonathan: happy to provide input
<npdoty> issue-31: might be related to issue-134 around short-term retention of logs
<trackbot> Notes added to ISSUE-31 Minimization -- to what extent will minimization be required for use of a particular exemption? (conditional exemptions).
Jonathan: Explained in email,
issue is in defining de-id there is a substantive standard,
what is the aim of de-identification
... to make it hard or impossible. Then non-normative examples that are essentia to illustrating the standard
... we could have no non-normative examples, or detailed non-normative examples
... Dan and Shane are far apart on non-normative examples
<rigo> AFAI understand, normative and non-normative considerations of de-identification are different tasks and should be continued
<dan_auerbach> hey i'm on the call now. what is the red/yellow/green ISSUE?
Jonathan: the non-normative is an important issue seperate from normative language
<trackbot> ISSUE-188 -- Definition of de-identified (or previously, unlinkable) data -- open
<trackbot> ISSUE-191 -- Non-normative Discussion of De-Identification -- raised
Peter: I hope that within our group that people that will tell these two seperate things
<npdoty> Shane, would you say your action 402 is more related to the non-normative examples?
<dan_auerbach> i don't feel strongly about combining into one or not, so long as the substance of both issues is accounted for
<WileyS> Agree with Jonathan - we'll likely not find agreement here as Jonathan and Dan want pure technical solutions and are not willing to accept anything that relies on technical, operational, and administrative controls as a fair solution.
<npdoty> note to nick: make sure there are clear links between issues 188 and 191
Peter: make sure we have linking
between two issues
... we have more time, if anyone wants to bring anything up
<WileyS> Nick - to be honest I hoping to provide draft text for both on 402 (normative and non-normative)
Peter: next week Matthias will
... in two weeks we will be back on compliance
... I hope people are trying to figure out overall packages they can live with
<rigo> dan, the red/yellow/green is the discussion between Rob and Shane on reducing identification data into pseudonymity and unlinkability
<WileyS> Nick - but agree with Jonathan while we'll likely agree on normative, we'll not agree on non-normative
Peter: thank you for your good work
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/pictorally/pictorially/ Found ScribeNick: Yianni Inferring Scribes: Yianni Default Present: +1.202.587.aaaa, JeffWilson, efelten, +1.646.654.aabb, Jules_Polonetsky, eberkower, Wendy, Rigo, +52661100aacc, +1.215.286.aadd, jchester2, npdoty, +1.202.587.aaee, +1.646.827.aaff, Yianni, susanisrael?, moneill2, phildpearce, Peder_Magee, Fielding, WileyS, Chris_IAB, rvaneijk, paulohm, vinay, hwest, +1.202.257.aagg, robsherman, Chris_Pedigo, Craig_Spiezle, hefferjr, mecallahan, [Microsoft], jackhobaugh, marcgroman, schunter, +1.650.365.aahh, sidstamm, dwainberg, adrianba, Amy_Colando, David_MacMillan, Brooks, RichardWeaver, +1.646.666.aaii, chapell, kulick, Walter, +1.650.465.aajj, vincent, Jonathan_Mayer, johnsimpson, Dan_Auerbach Present: +1.202.587.aaaa JeffWilson efelten +1.646.654.aabb Jules_Polonetsky eberkower Wendy Rigo +52661100aacc +1.215.286.aadd jchester2 npdoty +1.202.587.aaee +1.646.827.aaff Yianni susanisrael? moneill2 phildpearce Peder_Magee Fielding WileyS Chris_IAB rvaneijk paulohm vinay hwest +1.202.257.aagg robsherman Chris_Pedigo Craig_Spiezle hefferjr mecallahan [Microsoft] jackhobaugh marcgroman schunter +1.650.365.aahh sidstamm dwainberg adrianba Amy_Colando David_MacMillan Brooks RichardWeaver +1.646.666.aaii chapell kulick Walter +1.650.465.aajj vincent Jonathan_Mayer johnsimpson Dan_Auerbach WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 29 May 2013 Guessing minutes URL: http://www.w3.org/2013/05/29-dnt-minutes.html People with action items: swire[End of scribe.perl diagnostic output]