02:22:46 <npdoty> npdoty has joined #dntd
16:28:28 <RRSAgent> RRSAgent has joined #dntd
16:28:28 <RRSAgent> logging to http://www.w3.org/2013/02/12-dntd-irc
16:28:53 <Zakim> +johnsimpson
16:29:52 <Zakim> +Dan_Auerbach
16:30:20 <Zakim> +BerinSzoka
16:30:42 <johnsimpson> what phone is in room? heard dan well…not so clear from room
16:31:43 <Yianni> http://www.w3.org/wiki/Privacy/DNT-Breakouts
16:31:53 <BerinSzoka> BerinSzoka has joined #DNTD
16:32:01 <BerinSzoka> I just joined. could you send that link again?
16:32:12 <robsherman> yianni: First topic — what term should we use to describe "unlinkable" / "deidentified" / etc.?
16:32:31 <robsherman> … Concern is that there's always a chance of reidentification since always a chance.
16:32:40 <johnsimpson> someone typing near telephone should mute
16:32:52 <BerinSzoka> unlinkable = unfair & deceptive trade practice! ;)
16:33:02 <aleecia_> zakim, code?
16:33:02 <Zakim> the conference code is 26634 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), aleecia_
16:33:04 <BerinSzoka> much like "Do Not Track"...
16:33:13 <BerinSzoka> link again, please?
16:33:29 <robsherman> robsherman:  Deidentified.
16:33:36 <Zakim> +Aleecia
16:34:02 <BerinSzoka> how about "Anonymish?"
16:34:17 <BerinSzoka> or "Pseudononymish?"
16:34:32 <BerinSzoka> Or... Deidentifish?
16:34:50 <robsherman> What's the difference between "deidentified" and "anonymous"?
16:34:54 <wseltzer> wseltzer has joined #dntd
16:34:55 <aleecia_> perfect for all your phishing needs
16:35:16 <robsherman> … "Deidentified" covers both unlinkable and what could be relinkable
16:35:25 <robsherman> yianni:  Anyone on call have a view on this?
16:35:27 <dan_auerbach> I don't feel strongly either way
16:35:38 <dan_auerbach> but the substance matters more than the word we use
16:35:42 <aleecia_> If we've started, note on the phone I cannot hear well at all
16:35:56 <aleecia_> And we appear not to have a scribe
16:36:05 <dan_auerbach> i'm in your situation, aleecia_
16:36:11 <robsherman> Thomas:  If deidentified is closer to anonymous data, then deidentified is less able to explain "unlinked."  If we use "unidentified," then we are closer to both ideas - unlinkable but also acknowledge the possibility of reidentification.
16:36:21 <robsherman> Rachel_Thomas:  Are we getting too far into semantics?
16:36:24 <BerinSzoka> again, could you please send the link again to the questions?  some of us joined the IRC after it was shared
16:36:39 <David_Stark> David_Stark has joined #dntd
16:36:47 <robsherman> Thomas:  We need to decide how far we are able to go and come up with a way to describe it.
16:36:56 <aleecia_> If someone in the room could please scribe, those of us on the phone might be able to keep up
16:36:57 <BerinSzoka> AMEN, Rachel
16:37:03 <aleecia_> thank you, Rob
16:37:04 <robsherman> Rachel_Thomas:  Deidentified implies that you have taken reasonable steps to unlink; unlinkable is an impossibility.
16:37:30 <aleecia_> note that unlinkable means something specific and different in the EU
16:37:30 <robsherman> yianni:  robsherman made this point - we've done this in the HIPAA context and elsewhere.  What we say in the text is reasonableness.
16:37:31 <BerinSzoka> could whoever's typing move away from the mic? it's loud
16:37:51 <robsherman> Thomas:  Explain that there's a small gray area that's not completely anonymous.
16:38:08 <robsherman> Yianni:  "Reasonable deidentification" conveys that there's always the chance of reidentification, but has to be a low chance.  Are you okay with that?
16:38:09 <robsherman> Thomas: Yes.
16:38:22 <aleecia_> "deidentification" to me suggests after a process.
16:38:29 <robsherman> Dan_Auerbach:  Can we all agree that whatever word we use shouldn't inform the details of the process or standard we agree upon?
16:38:34 <robsherman> Rachel_Thomas: What do you mean?
16:38:51 <robsherman> Dan_Auerbach:  Don't feel strongly about terminology, but I do care about substance.
16:39:00 <robsherman> Yianni:  Agree.  Just because we use the word deidentified or unlinkable.
16:39:15 <robsherman> Rachel_Thomas:  But they're different concepts - we're trying to decide whether working toward deid or unlinkability.
16:39:55 <robsherman> robsherman: I think consensus is that we're not going for theoretical unlinkability but for reasonable delinking.
16:39:59 <dan_auerbach> i do not suggest we go for theoretical impossibility
16:40:06 <robsherman> yianni:  Seems reasonable.  Should we look at FTC language?
16:40:16 <Yianni> http://www.w3.org/wiki/Privacy/DNT-Breakouts
16:40:31 <Zakim> +vincent
16:40:49 <bryan> bryan has joined #dntd
16:41:11 <BerinSzoka> #DoNotCough
16:41:13 <Yianni> http://www.w3.org/wiki/Privacy/DNT-Breakouts
16:41:16 <dan_auerbach> haha
16:41:18 <johnsimpson> apologies was called away from phone briefly
16:41:36 <robsherman> … What's wrong with this language?  Why shouldn't we use it?
16:41:46 <aleecia_> FTC:
16:41:47 <aleecia_> data is not “reasonably linkable” to the extent that a company: (1) takes reasonable measures to ensure that the data is de-identified;  (2) publicly commits not to try to reidentify the data; and  (3) contractually prohibits downstream recipients from trying to re-identify the data.  Commission's definition of "de-identified":  "First, the company must take reasonable measures to ensure that the data is de-identified. This means that the company must [CUT]
16:42:03 <robsherman> dan_auerbach:  FTC language is a good starting point.  Makes sense and not too prescriptive.  Also favor adding to it the idea that there should be privacy penetration testing.
16:42:31 <aleecia_> cut off, once more: "First, the company must take reasonable measures to ensure that the data is de-identified. This means that the company must achieve a reasonable level of justified confidence that the data cannot reasonably be used to infer information about, or otherwise be linked to, a particular consumer, computer, or other device."
16:42:33 <robsherman> … Having people try to reidentify data.  Has to be some sort of normative way to distinguish companies that just try to hash IDs and companies that make a more serious effort to it.
16:42:55 <vincent> vincent has joined #dntd
16:43:00 <robsherman> rachel_thomas:  Sounds like you're onboard with the idea as long as we come up with some clarity around what deidentification is?
16:43:04 <robsherman> Dan_Auerbach: Yes.
16:43:26 <robsherman> ?:  Should we be requiring people to publicly commit not to reidentify?
16:43:46 <robsherman> yianni:  I think that's what we are trying to do here - get people to publicly commit to follow a standard.
16:43:51 <robsherman> bryan:  Privacy policy.
16:45:34 <robsherman> robsherman:  Much cleaner to not have lots of individual "public commitments," as FTC would have under Section 5.  Let's just agree on what's required — for example, not reidentifying data — and treat server response as the public commitment.
16:45:36 <tlr> rrsagent, make record public
16:45:47 <robsherman> yianni:  Is it better to define reasonableness here?  Have examples?
16:45:59 <robsherman> Rachel_Thomas:  There's already a legal standard for "reasonableness."
16:46:02 <vincent> q?
16:46:03 <bryan> q?
16:46:07 <bryan> q+
16:46:09 <robsherman> Dan_Auerbach:  Helpful to have examples.
16:46:17 <robsherman> ack bryan
16:46:20 <johnsimpson> q+
16:46:39 <rachel_thomas> For reference (since we're also looking at the FTC language) here is the DAA definition of De-Identification Process:  Data has been De-Identified when an entity has taken reasonable steps to ensure that the data cannot reasonably be re-associated or connected to an individual or connected to or be associated with a particular computer or device.  An entity should take reasonable steps to protect the non-identifiable nature of data if it is dist[CUT]
16:46:53 <rachel_thomas> (cont) Affiliates and obtain satisfactory written assurance that such entities will not attempt to reconstruct the data in a way such that an individual may be re-identified and will use or disclose the de-identified data only for uses as specified by the entity. An entity should also take reasonable steps to ensure that any non-Affiliate that receives deidentified data will itself ensure that any further non-Affiliate entities to which such dat[CUT]
16:46:58 <robsherman> bryan: Regarding examples, that's something that advocacy groups or public sites will do as far as creating best practices.  Maybe something that could be documented through W3C community group process, webplatform.org, etc.  Agree with Rachel that we should limit non-normative language within spec itself.
16:47:04 <aleecia_> I think examples are helpful
16:47:06 <robsherman> ack johnsimpson
16:47:10 <bryan> q-
16:47:14 <dan_auerbach> q+
16:47:14 <aleecia_> Asking people to implement this without context is hard
16:47:20 <robsherman> johnsimpson:  Probably don't want to define "reasonable" in normative language.
16:47:23 <rachel_thomas> i don't feel strongly about not having examples (just depends on what they are)
16:47:30 <aleecia_> And we likely do NOT want to hard code what is required
16:47:38 <robsherman> … We do have specific examples, and it would be tremendously helpful to have that language included in a non-normative way.
16:48:05 <aleecia_> +1
16:48:10 <dan_auerbach> +1
16:48:19 <robsherman> robsherman:  Agree w/ aleecia that hard-coding technology is really hard to implement and will break the standard 5 years from now.
16:48:26 <aleecia_> Could put them into an appendix if they clutter up the text
16:48:34 <robsherman> yianni:  What examples do people have as "clearly good enough" or "clearly not good enough"?
16:48:40 <rachel_thomas> q+
16:48:47 <Yianni> q?
16:49:01 <aleecia_> Not good enough: removing names, removing unique ids
16:49:18 <robsherman> Sam: Looking at Ed's examples, he talked about admin/procedural controls that leaves database or is reported outside of controlling entity.  Focusing on that would be interesting.  Looking at 3rd parties, how they anonymize and report out, that's really what we're talking about in terms of protecting privacy.
16:49:40 <robsherman> … Lots of technologies to do that.  Will be different for every entity.  So I'd like to focus on what are the controls that keep identifiable info from leaking out.
16:49:44 <Yianni> ack: dan-auerbach
16:49:45 <robsherman> … No specific examples.
16:49:47 <Zakim> -Dan_Auerbach
16:49:57 <robsherman> ack rachel_thomas
16:50:01 <dan_auerbach> whoops seems i've dropped off the call
16:50:06 <dan_auerbach> will try back in a moment
16:50:19 <robsherman> rachel_thomas:  In IRC, put in DAA language on deidentification.  We don't have specific examples, but text is helpful in terms of explaining what's meant by de-identification.
16:50:21 <aleecia_> (The DAA text isn't bad)
16:50:53 <robsherman> unmute aleecia_
16:50:57 <robsherman> zakim, unmute aleecia_
16:50:57 <Zakim> sorry, robsherman, I do not know which phone connection belongs to aleecia_
16:51:05 <dan_auerbach> agree that DAA text is OK, though FTC seems a little better to me
16:51:06 <aleecia_> I'm following via scribes - cannot hear well
16:51:15 <aleecia_> I'm guessing I was unmuted for a reason I missed...
16:51:18 <robsherman> rachel_thomas:  [reads through DAA language]
16:51:56 <rachel_thomas> i'm quoting from https://www.aboutads.info/resource/download/Multi-Site-Data-Principles.pdf
16:52:03 <robsherman> yianni:  Any specific technical measures?
16:52:04 <rachel_thomas> page 8  :)
16:52:14 <aleecia_> Ah, sorry. Rachel will be better taking that than I would anyway, but I note it's similar to FTC's in large measure. Same direction.
16:52:21 <robsherman> … Any comments on Ed's presentation about hashing or k-anonymity not being a good method?
16:52:43 <robsherman> Sam:  I'm a big opponent of hashing.  It's great but has its limits.  If you're using it to anonymize or other deidentify, some day it will be broken.
16:52:49 <robsherman> q+
16:52:54 <dan_auerbach> q-
16:52:56 <bryan> q+
16:52:59 <robsherman> … Have to come up with better ways of doing this long-term.
16:53:12 <robsherman> rachel_thomas:  We don't need to identify specific standards.
16:53:12 <rachel_thomas> q+
16:53:13 <Yianni> q?
16:53:16 <robsherman> ack robsherman
16:53:18 <aleecia_> My hope is that DAA's members won't have to change much, though from Shane's questions, presumably Yahoo! would
16:53:19 <johnsimpson> Q+
16:53:30 <dan_auerbach> (i'm unable to rejoin the call -- it seems to be on W3C's side? -- so will follow via scribe
16:53:54 <aleecia_> (Dan, me too)
16:53:54 <bryan> robsherman: talking about specific tech is a mistake, also demonizing hashing, there are good uses in the de-id context
16:53:57 <vincent> it strongly depends of how often you change the seed you use to hash
16:54:24 <Yianni> q?
16:54:28 <vincent> q+
16:54:42 <aleecia_> Vincent - and the richness of data collected
16:54:44 <robsherman> Sam:  Good examples of how hashing works, but it's in the context of a specific data set.  When you become able to correlate, things break down, so hard to say whether a particular technique will work.
16:54:45 <dan_auerbach> here's an example of something which is NOT good enough: a wide table keyed with pseudonyms (say, hashes of cookies), but which also has timestamps, urls, etc
16:54:46 <robsherman> ack bryan
16:55:16 <robsherman> bryan:  This is a point in time where anything we write on technology today will be superseded tomorrow.  Let's establish a reasonable expectation, let technologists figure out what is reasonable today, and not put it in the spec.
16:55:20 <robsherman> ack johnsimpson
16:55:32 <robsherman> johnsimpson:  If we know what works, it should be cited in non-normative language as an example.
16:55:42 <robsherman> … Also, in normative language, we should require that there be transparency about method you use to hash.
16:55:49 <robsherman> q+ to respond to johnsimpson
16:55:51 <vincent> for the record, Google used to change (still does)  the key to hash search logs everyday (see: http://searchengineland.com/anonymizing-googles-server-log-data-hows-it-going-15036)
16:56:04 <robsherman> … People need to understand what you're doing.
16:56:06 <robsherman> ack rachel_thomas
16:56:25 <robsherman> rachel_thomas:  Agree strongly for the sake of consumer privacy and data security.  The more specific you are about specific methods of protecting data, the less secure they are.
16:56:37 <vincent> and we're talking about a first anonymizing its search logs, not a third party (imho third party should provide stronger garantees)
16:56:38 <aleecia_> security through obscurity has failed time and again
16:56:42 <robsherman> … That's why the law has been comfortable with the idea of not describing specific methods.
16:56:47 <dan_auerbach> I agree with bryan there shouldn't be normative language specifying technology, but non-normative examples are helpful
16:56:57 <robsherman> ack vincent
16:57:02 <robsherman> q-
16:57:07 <BerinSzoka> hey, John, how about #DoNotSnark?
16:57:21 <robsherman> vincent:  We say data cannot be used by the actor to reidentify.  But don't say it can't be used by ANYONE.
16:57:28 <robsherman> … If I share data with another actor, it might use the data to reidentify.
16:57:30 <aleecia_> Berin, I take it you've decided not to honor that? (...says the pot to the kettle)
16:57:31 <Yianni> q?
16:57:31 <robsherman> q+
16:57:51 <BerinSzoka> as John said: "whatever" ;)
16:57:53 <robsherman> yianni:  Do you mean just contractually - have you have contractual promises not to reidentify?
16:58:00 <aleecia_> Vincent - I could imagine daily not being enough
16:58:03 <robsherman> vincent:  Just talking about language of the draft.
16:58:17 <robsherman> yianni:  I'd hope contractual language already covers.
16:58:25 <robsherman> rachel_thomas:  FTC language already says this.
16:58:31 <Yianni> q?
16:58:40 <Yianni> ack robsherman
16:58:53 <rachel_thomas> q+
16:58:56 <vincent> ok, the barebone does not reflect that :"contractually prohibits downstream recipients from trying to re-identify the data. "
16:59:11 <aleecia_> currently not hearing any objections to the FTC defn (and not hearing, so perhaps missing things vital)
16:59:20 <Yianni> q?
16:59:23 <aleecia_> could we just adopt FTC lang and add examples?
16:59:31 <robsherman> robsherman: Wouldn't need to have specific language that says this; already covered by "reasonableness" precedent.
16:59:36 <robsherman> ack rachel_thomas
16:59:37 <dan_auerbach> aleecia_: that'd be my favored approach
16:59:44 <robsherman> rachel_thomas:  DAA makes the same point.  We're in violent agreement here.
16:59:46 <vincent> aleecia_, actually I'agree that every day is not enough
16:59:49 <aleecia_> any objections?
16:59:55 <robsherman> yianni:  Next question - on pseudonyms.
16:59:59 <dan_auerbach> however, the examples should be real
17:00:12 <aleecia_> can we actually just nail this down (for the group) right now?
17:00:34 <robsherman> Thomas: From my presentation today, there's a split between anonymous and pseudonymous.  Anonymous is nearly absolutely impossible, and with pseudonymous someone has the key to reidentify.
17:00:44 <SamS> Q+
17:01:00 <bryan> q+
17:01:01 <Yianni> q?
17:01:01 <robsherman> yianni:  [summarizes Dan's comment from IRC].
17:01:38 <Thomas> Thomas has joined #dntd
17:01:57 <dan_auerbach> regarding pseudonyms, it's dangerous to think of data that way because it leads to the false impression that only certain fields are the "identifiers", whether they be real names or pseudonyms
17:01:57 <robsherman> SamS: Comes down to a contract that says, if I get data, I won't try to reidentify it.  Even if it's pseudonymous or a weak version of anonymity, as long as I protect data, don't leak it, and don't reidentify, it's equivalently the same thing.  But the burden is on me to be sure I have the right admin controls to be sure all of this happens.  Ultimately that's where we are going.
17:02:07 <dan_auerbach> in fact, each field will have some bits of identifying information
17:02:09 <vincent> where are we standing on "hashing" do we agree that it's not enough or it's the opposite?
17:02:16 <robsherman> yianni:  You think contractual language does a lot?
17:02:19 <robsherman> SamS: Yes.
17:02:24 <robsherman> ack bryan
17:02:36 <vincent> q+
17:02:39 <robsherman> bryan:  Want to be sure we're still talking about a third party.
17:02:51 <vincent> I think there is a misunderstanding about pseudonym definition
17:02:52 <aleecia_> right now i cannot imagine a straight up pseudonym helping
17:02:55 <vincent> q-
17:02:55 <rachel_thomas> q+
17:02:56 <dan_auerbach> i want strong guarantees on the data itself, not just contracts
17:03:04 <vincent> agree with robsherman
17:03:05 <aleecia_> replacing one GUID with another does not help
17:03:11 <Thomas_Schauf> Thomas_Schauf has joined #dntd
17:03:15 <Yianni> q?
17:03:17 <vincent> for instance cookieID is a pseudonym
17:03:18 <rachel_thomas> From Thomas' presentation this morning: “Pseudonymising” shall mean replacing the data subject’s name and other identifying features with another identifier in order to make it impossible or extremely difficult to identify the data subject.
17:03:19 <robsherman> robsherman: (Clarifies use of pseudonyms in third party context)
17:03:30 <dan_auerbach> aleecia_: especially when that guid is linked with tons of other identifying information
17:03:32 <vincent> IP address+ User Agent could be a pseudonym
17:03:35 <aleecia_> yes
17:03:49 <David_Stark> q+
17:03:53 <Yianni> q?
17:03:59 <rachel_thomas> Pseudonymous info is...Unique identifier does not identify a specific person, but could be associated with an individual. Includes:  Unique identifiers, biometric information, usage profiles not tied to a known individual. Until associated with an individual, data cannot be treated as anonymous.
17:04:01 <robsherman> q- SamS
17:04:01 <aleecia_> and that's my problem with hashing (and agree, rotation helps there, potentially)
17:04:06 <robsherman> ack Rachel_Thomas
17:04:20 <robsherman> Rachel_Thomas:  Capturing info from Thomas's presentation this morning.
17:04:24 <robsherman> ack David_Stark
17:04:37 <vincent> imho, hasing a cookie ID does not bring a lot of garantee (if any)...
17:04:52 <aleecia_> +1 vincent
17:05:02 <dan_auerbach> getting into the mentality that certain fields are the "identifying" ones (e.g. a cookie, hash of ip+ua) is a mistake
17:05:12 <robsherman> David_Stark:  Thought the conversation this morning was excellent.  At my market research co, when people who participate in a survey, we assign them a pseudonymous identifier that allows for quality control. Without this, you'd have know control.  Just anyone could come in and respond many times - fundamentally undermining data quality.
17:05:36 <dan_auerbach> if i visit the domain, webmail.danauerbach.org, that field becomes identifying
17:05:37 <BerinSzoka> whoever was typing but just stopped--was REALLY loud
17:05:50 <Yianni> q?
17:06:27 <robsherman> … Only have identifiers of panel members and their numbers.  Researchers have access to survey responses.  But nobody in our company has access to individuals and their responses.
17:06:56 <robsherman> yianni:  You're bringing up the point of administrative controls, which Sam also mentioned.
17:07:07 <aleecia_> as a suggestion: you could have a marker in a cookie of the number of times people have taken a survey, rather than the unique id on the person
17:07:08 <johnsimpson> q?
17:07:18 <robsherman> … Currently, FTC language doesn't mention this.  Should we address this in non-normative language?
17:07:28 <David_Stark> q+
17:07:33 <robsherman> ack David_Stark
17:07:36 <aleecia_> that isn't so bad when you're only dealing with one company, rather than trying to push out a change across multiple parties working together in an ecosystem
17:07:40 <robsherman> David_Stark:  Great idea, if we can provide examples.
17:07:54 <bryan> with proper access controls on pseudonym mapping, I agree that this meaning of pseudonym supports the goal of de-identifying data
17:08:06 <robsherman> … Makes a lot of sense.  We see that language in data protection laws - admin, technical, and physical controls.  Let's say that.
17:08:12 <robsherman> yianni:  Any disagreement?
17:08:17 <aleecia_> with?
17:08:20 <Yianni> q?
17:08:33 <robsherman> … with the idea that organizational measures should be taken into account?
17:08:47 <aleecia_> for first parties, not an issue
17:08:55 <aleecia_> for third parties, not sure why we'd take them into account?
17:08:59 <robsherman> … One danger I can see here is organizational measures is the government problem.  Even if you have great organizational measures, the govt could come in and reidentify.
17:09:01 <vincent> q+
17:09:17 <aleecia_> i think the conversation was about a survey people agreed to take, which makes for first party issues
17:09:23 <rachel_thomas> q+
17:09:26 <Yianni> q?
17:09:34 <robsherman> robsherman:  Shouldn't have one standard in normative and a different one in non-normative
17:09:36 <robsherman> ack vincent
17:09:39 <aleecia_> the first party might release data later and want to de-id, but no need to worry about org measures then
17:09:45 <aleecia_> not seeing how that's relevant to us here
17:09:47 <robsherman> vincent:  One scenario people are considering is the rogue engineer.
17:10:01 <Yianni> q?
17:10:01 <robsherman> … Someone has to have access to the data, so the org measures don't really matter.
17:10:02 <aleecia_> and again, my apologies for not being able to hear.
17:10:02 <SamS> Q+ 1
17:10:04 <robsherman> ack rachel_thomas
17:10:26 <robsherman> rachel_thomas: Are you suggesting different standards for protection of data for consumer privacy and for government access?
17:10:27 <SamS> Q+
17:10:36 <robsherman> yianni:  No - I don't think you can do that separately.
17:10:38 <robsherman> q- 1
17:10:51 <Yianni> q?
17:10:59 <robsherman> rachel_thomas:  We can't get outside of reasonableness.  You can take action against a rogue employee and that's already covered.
17:11:09 <robsherman> yianni:  Would you say that admin controls go into the concept of "deidentified"?
17:11:12 <robsherman> rachel_thomas:  Yes.
17:11:16 <vincent> aleecia, bridge is not reachable?
17:11:26 <robsherman> s/concept of "deidentified"/concept of "reasonableness"
17:11:49 <robsherman> Sam:  We already do all of this.
17:12:07 <robsherman> yianni:  There's going to be some pushback for including organizational measures within the concept of reasonable technical measures.  Govt access.
17:12:13 <Yianni> q?
17:12:18 <robsherman> … Does that mean that admin controls shouldn't count as a part of technical measures?
17:12:22 <vincent> rachel_thomas, you can make it very very hard (if not impossible) for someone to technically reidentify the data
17:12:26 <robsherman> ack SamS
17:12:38 <aleecia_> on bridge. call quality is less than ideal.
17:12:49 <vincent> not just "reasonably" hard
17:12:50 <dan_auerbach> vincent: i am unable to reach bridge at all
17:12:52 <robsherman> SamS: It's pretty basic - administrative measures prevent people accessing data to reidentify.
17:12:54 <aleecia_> it's like hearing the words without any spaces
17:13:06 <robsherman> … If I can get at data in a way that bypasses proper controls, I can maybe reidentify.
17:13:08 <Yianni> q?
17:13:26 <robsherman> bryan:  It has strong value.  It's something we do for a variety of regulatory requirements already.  Tons of data and admin controls are only way to meet those requirements.
17:13:27 <robsherman> q+
17:13:29 <dan_auerbach> to clearly state my opposition to this, administrative controls are NOT enough
17:13:38 <Yianni> q?
17:13:39 <dan_auerbach> we need real de-identification in the data itself
17:14:00 <robsherman> MikeZ:  Some people have this in place.  Small companies.  Which is why you have a sliding scale in FTC standard.  We're solving for the web, not just a handful of big companies.
17:14:08 <Yianni> q?
17:14:08 <robsherman> yianni:  That's the problem with having specific examples in text.
17:14:20 <robsherman> bryan: Same goes for sophistication of tech approaches that we mandate.
17:14:33 <vincent> aleecia_, dan_auerbach have you retried? call quality is fine for me
17:14:54 <johnsimpson> quality ok for me, too
17:15:03 <aleecia_> zakim, code?
17:15:03 <Zakim> the conference code is 26634 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), aleecia_
17:15:08 <Zakim> -Aleecia
17:15:20 <dan_auerbach> vincent, i've retried several times but am just unable to connect, but will do so one more time...
17:15:30 <Zakim> +Aleecia
17:15:39 <Yianni> q?
17:15:41 <robsherman> ack robsherman
17:15:47 <aleecia_> did get back in. is somewhat better
17:16:06 <Zakim> +Dan_Auerbach
17:16:08 <aleecia_> still scribe-dependent but that's ok
17:16:12 <robsherman> robsherman: Concept of reasonableness encompasses admin, tech, and physical practices, and the specific steps might vary based on circumstances.
17:16:21 <Yianni> q?
17:16:51 <dan_auerbach> vincent, now connected but call quality is quite bad
17:16:52 <robsherman> yianni:  Would having specific examples of what's appropriate be helpful in bridging the gap between John Simpson's demand for transparency and the need to keep it security.
17:17:08 <johnsimpson> +q
17:17:16 <robsherman> rachel_thomas:  Security information is kept secret because disclosing it gives hackers a way in.
17:17:21 <Yianni> q?
17:17:22 <robsherman> … Let's protect the information in the most effective way.
17:17:26 <aleecia_> getting enough of this - depending on "we don't tell people about our security measures" does not offer real protection
17:17:29 <robsherman> bryan:  Also opens the door to social engineering around company practices.
17:17:35 <vincent> q+
17:17:36 <robsherman> ack johnsimpson
17:17:47 <robsherman> johnsimpson:  Not calling for "putting the secret sauce of everything you do out there."
17:18:05 <dan_auerbach> i do think we need transparency here, +1 to johnsimpson
17:18:07 <robsherman> … What I think needs to be explained publicly is the category of measures that are taken.  Not enough to say "reasonable".
17:18:15 <robsherman> rachel_thomas:  What would be reasonable in your opinion?
17:18:43 <aleecia_> if we had a high, specific standard transparency wouldn't be necessary, but that would break future-proofing
17:18:45 <robsherman> johnsimpson:  Difference between security and fraud, where getting specific could tip your hand. But you could say, if you believe that hashing is reasonable, you can say you rely on hashing.
17:18:51 <rachel_thomas> q+
17:18:57 <robsherman> … You can describe techniques that would provide meaningful insight without giving away the store.
17:19:12 <robsherman> rachel_thomas:  But you've just narrowed the world in terms of what a hacker needs to think about.
17:19:24 <dan_auerbach> +1 to aleecia
17:19:26 <robsherman> … You're narrowing a bunch of other things a hacker will need to think about to get into your system.
17:19:27 <vincent> rachel_thomas, I'd argue with taht
17:19:31 <SamS> +q
17:19:31 <aleecia_> anyone who can break your hash will be able to identify that's what you did without disclosure
17:19:32 <robsherman> ack vincent
17:20:06 <robsherman> vincent:  Transparency doesn't provide a solution for hackers to break in.  I don't see how it would allow someone to break into your system.
17:20:08 <robsherman> ack sams
17:20:18 <rachel_thomas> q-
17:20:30 <aleecia_> how useful is this detail to anyone making privacy choices? likely not very. so while i disagree with Rachel on this one, i'm also not strongly pounding the table to support John
17:20:38 <robsherman> SamS: Let's say I published a privacy policy on my website that showed all of the encryption techniques that I use to anonymize data.  How does that actually protect the data that I have?
17:20:55 <robsherman> … Will consumers read it and say, "They use a lot of encryption?  That's really good."
17:20:58 <aleecia_> q+
17:21:12 <robsherman> yianni:  So you're saying there's no information that is worth releasing.
17:21:16 <rachel_thomas> q+
17:21:34 <robsherman> SamS:  Saying that you use reasonable technical measures to protect the data - which is what the FTC requires - then that's reasoable. And if I have a breach, people will hold me accountable.
17:21:39 <Yianni> q?
17:21:40 <robsherman> … But using Encryption v.1 vs v.2 isn't going to make a difference.
17:21:42 <robsherman> ack aleecia_
17:22:11 <rachel_thomas> agree with aleecia!
17:22:14 <robsherman> aleecia:  I think you're not giving away the store to announce which of the few available measures you might be taken.  In terms of whether end users will understand the difference, no.  If it were in a privacy policy, no.
17:22:26 <rachel_thomas> consumers won't know what the techniques mean anyway.
17:22:32 <robsherman> … But what this could be helpful for is to require companies themselves to write down what they do and review it periodically to make sure it's what they do.
17:22:43 <robsherman> … There's no state secret or competitive advantage.
17:22:55 <rachel_thomas> internal policies are different from public policies - no one is saying that companies can't review their internal policies to ensure that they're keeping their practices up to date.
17:22:56 <robsherman> … Most value of privacy policies these days is for internal analysis.
17:22:58 <Yianni> q?
17:23:02 <robsherman> ack rachel_thomas
17:23:21 <vincent> q+
17:23:40 <aleecia_> smaller cos will not
17:23:44 <robsherman> rachel_thomas:  Agree with aleecia that consumers won't understand what they are reading in privacy policies.  I'd also note that there are endless internal policies for companies that describe in much greater detail what you do.  So I don't think that leaving it out of privacy policy omits the process of internal analysis.
17:23:45 <aleecia_> major cos will
17:23:46 <robsherman> ack vincent
17:24:00 <dan_auerbach> rachel, "privacy and data security" is too broad to cover what we're after, which is ensuring data is de-identified
17:24:16 <robsherman> vincent:  Maybe a few users might like to know this, and this data might be useful.  For example, you might want to know if data you deleted can still be linked back to you.
17:24:24 <robsherman> q+
17:24:25 <Yianni> q?
17:24:26 <aleecia_> having "if you share de-id'ed data, state what you do to ensure it's actually de-id'ed" is a small ask
17:25:49 <vincent> disclosing an alogirhtm without data won't help hackers to break in, just help the community to assess the security of your algorithms
17:26:58 <vincent> q+
17:27:00 <robsherman> robsherman: We need to be clear about what problem we're trying to solve.  User transparency?  Challengeability?  Forcing internal analysis?  I tend to think over time it's bad to disclose security practices because it creates a vulnerability.
17:27:00 <SamS> +q
17:27:03 <Yianni> q?
17:27:05 <aleecia_> so, i'd say we don't have agreement here, but could have agreement on adopting the FTC text and adding examples
17:27:18 <robsherman> … Beyond that, the more transparent you are — sufficient to allow people to test vulnerabilities — you actually become more vulnerable.
17:27:19 <robsherman> ack vincent
17:27:37 <dan_auerbach> i'd like to voice my strong objection to conflating "security" with the specific area of de-identification
17:27:40 <aleecia_> can we do that and leave transparency for the full group? if we're split here, odds are we're split with more people too
17:27:46 <aleecia_> not sure agreeing here has much value
17:27:47 <dan_auerbach> they are very different things
17:27:51 <robsherman> vincent:  Google talks about how they anonymize their server logs.  Doesn't create vulnerabilities but does help to evaluate.
17:28:11 <robsherman> ack SamS
17:28:18 <Yianni> q?
17:28:21 <robsherman> SamS: We're not going to come to agreement to get to minimum standards here.
17:28:25 <robsherman> q-
17:29:17 <Yianni> http://www.w3.org/wiki/Privacy/DNT-Breakouts
17:29:17 <robsherman> yianni:  Aleecia made a good point.  FTC language is a reasonable starting point.  Examples could be helpful if they don't limit what companies can do or limit tech advancement.
17:29:26 <MikeZaneis> MikeZaneis has joined #dntd
17:29:41 <robsherman> … When I first read existing "unlinkable" language, I was confused about why it was here.
17:29:54 <robsherman> … Specifically, why do we say "commercially reasonable steps"?
17:30:01 <dan_auerbach> apologies all, i have to take off
17:30:04 <Zakim> -Dan_Auerbach
17:30:06 <robsherman> … Should it be in the document?  From a legal standpoint, "commercially" doesn't do much.
17:30:07 <Yianni> q?
17:30:07 <aleecia_> i'd drop "commercially"
17:30:07 <johnsimpson> should just be reasonable
17:30:13 <robsherman> bryan:  "Reasonable" is enough.
17:30:19 <aleecia_> and agree reasonable is sufficient
17:30:20 <robsherman> yianni: Anyone disagree?
17:30:20 <rachel_thomas> should be reasonable.  no need for commercial.
17:30:36 <robsherman> [General agreement that we should cut "commercially."]
17:30:48 <robsherman> yianni:  Also, "high probability"?
17:30:56 <Yianni> q?
17:31:01 <rachel_thomas> q+
17:31:05 <robsherman> ack rachel_thomas
17:31:35 <robsherman> rachel_thomas:  What is the context in which we're looking at this language?  I think these breakouts are designed to take us past what's already in the text.  We've been focused on de-id, so it's odd to be looking at a definition of "unlinkable."
17:31:52 <robsherman> yianni:  We had a statement earlier from Dan that he doesn't care what it's called as long as substantively that doesn't affect it.
17:31:57 <aleecia_> Let's please please please use a different term other than unlink
17:32:08 <robsherman> … Trying to figure out why we're saying what we're saying in the text.
17:32:20 <robsherman> … If it's substantively accurate to call it "de-id," we should call it that.
17:32:21 <Yianni> q?
17:32:25 <aleecia_> We've agreed to change that, but not what to -- if deid'ed works for everyone, let's run with that
17:32:54 <robsherman> rachel_thomas:  We had two definitions that we looked at earlier — FTC and DAA — that we agreed were good.  We shouldn't go back to draft.  Peter made clear that editing text from the draft should be done in the full group.
17:33:03 <robsherman> q+
17:33:09 <robsherman> yianni:  Depends on what we decide to call it.
17:33:20 <MikeZaneis> Q+
17:33:34 <robsherman> … So, with the text we have in the draft, we decided commercially should be cut.  Should we change "high probability"?
17:33:37 <robsherman> q+ later
17:33:42 <robsherman> ack robsherman
17:33:52 <Yianni> q?
17:33:56 <vincent> we could remove "high probability" as well
17:33:58 <robsherman> ack MikeZaneis
17:34:18 <aleecia_> None of these things are absolutes. High probability is about as good as I think we can reasonably get (no pun intended. This time.)
17:34:28 <robsherman> MikeZaneis:  "Unlinkable" vs "de-id."  I think "unlinkable" presents a unique challenge as we move forward when we talk about permitted uses, etc.
17:34:38 <robsherman> … We may as a group decide after x time, you should de-identify data.
17:34:39 <johnsimpson> seems to me "high probability" is necessary
17:34:54 <robsherman> … We identified reasons why companies should need to go back to re-identify.
17:35:06 <robsherman> … I know this is really about what the process for de-id might be, but if we're talking about unlinkable.
17:35:19 <robsherman> … Connotation of "unlinkable" is a more permanent break that would limit this group's long-term success.
17:35:22 <Yianni> q?
17:35:24 <aleecia_> If companies *can* re-identify globally, they have not actually de-id'ed in the first place
17:35:30 <robsherman> yianni:  Agree, especially if what we think of as unlinkable it wouldn't make sense to use that as the word.
17:35:57 <aleecia_> To beat a dead horse: unlinkable means something specific and different in Europe. We should use a different term.
17:36:30 <robsherman> ack robsherman
17:36:37 <aleecia_> As another example, if you can append data to a record based on new data you've collected, you don't have deidentified data
17:36:50 <johnsimpson> Q+
17:37:01 <robsherman> robsherman:  I think we shouldn't work off of old "unlinkable" definition if we've decided to move away from it.  We've identified DAA / FTC language as reasonable baseline, so let's start there.
17:37:15 <robsherman> yianni:  Do we think it's reasonable to start with FTC language?  DAA?  They're very similar.
17:37:22 <Yianni> q?
17:37:27 <bryan> +1 to avoid word-smithing the text here, and use DAA / FTC as base
17:37:27 <robsherman> ack johnsimpson
17:37:45 <robsherman> johnsimpson:  Earlier discussion was about using de-id data, but the way you get to de-id is to make it unlinkable.
17:37:53 <aleecia_> We appear to all be agreeing
17:38:07 <aleecia_> So close
17:38:11 <robsherman> … It seems like the definition of unlinkable is an excellent articulation of how you get to de-identification.
17:38:14 <Yianni> q?
17:38:38 <robsherman> yianni:  Personally, looking at text as proposed, it's similar to FTC with exception of "high probability."  Seems to be similar.
17:38:48 <robsherman> … For Option 1.  Option 2 seems very different.
17:38:53 <Yianni> q?
17:38:54 <aleecia_> I'd be happy to add "high prob" to FTC text, toss in a few examples, and go home.
17:39:30 <robsherman> q+
17:39:49 <MikeZaneis> Q+
17:40:37 <johnsimpson> Q+
17:40:52 <BerinSzoka> +1 to Rob
17:41:07 <aleecia_> Ok: that persuades me.
17:41:29 <aleecia_> (cannot understand current speaker, did mostly get Rob)
17:41:41 <aleecia_> Agree that there is utility to adopting FTC text unchanged.
17:41:45 <robsherman> robsherman:  Worry about tweaking FTC definition.  FTC will develop body of caselaw around de-id, and that will give guidance to industry.  If we add "high prob" to make people here happy, then it introduces uncertainty about how things diverge.
17:41:48 <robsherman> SamS: Agrees.
17:42:02 <aleecia_> Adding examples sounds reasonable, since I'm not sure implementers will get it
17:42:23 <johnsimpson> seems strange to adopt FTC text when we're developing a global standard
17:42:29 <BerinSzoka> does anyone NOT agree with Rob?
17:42:32 <johnsimpson> q?
17:42:33 <robsherman> MikeZaneis:  Hesitate to add adjectives where we don't know exactly what they do.  It seems like we're having a discussion in this group about whether there's any reason or possibility for re-identification.  Is the goal to completely break even the possibility for re-identification?
17:42:51 <robsherman> yianni:  Everyone here understands that when you de-identify data, there's a chance of reidentification.
17:42:58 <vincent> q+
17:43:04 <robsherman> … If you got to 100% certainty, the data would become almost useless
17:43:29 <robsherman> … So we're trying to come up with language we could move forward with.  If we just adopted FTC language without modification, would people be okay with it?
17:43:29 <vincent> q?
17:43:37 <aleecia_> Q was do we adopt FTC text? Yes, with examples.
17:43:41 <robsherman> MikeZaneis:  I don't think anyone's ready to sign off, but it's a good starting point for the discussion.
17:43:44 <aleecia_> And agree with Rob that not changing it has value
17:43:52 <Yianni> q?
17:43:58 <vincent> q-
17:44:04 <robsherman> Thomas:  Agrees with johnsimpson that there is legal opinion, and we need to think about whether it is globally adoptable.
17:44:23 <robsherman> q-
17:44:30 <robsherman> q- MikeZaneis
17:44:33 <robsherman> ack johnsimpson
17:45:02 <Thomas_Schauf> Thomas_Schauf has joined #dntd
17:45:04 <robsherman> johnsimpson:  I thought that the proposed bare-bones language was the result of many long discussions that took a lot of things into account, and we seem to be throwing those out the window.
17:45:16 <robsherman> … I'm also puzzled about the implications of going to a specific US agency's language.
17:45:23 <robsherman> … This needs to be thought through in terms of a global standard.
17:45:23 <Yianni> q?
17:45:49 <robsherman> yianni:  Thomas, do you think FTC language won't coincide with European standards?
17:46:08 <robsherman> Thomas:  We need to think about it, and also consider ongoing discussions about EU Directive.
17:46:26 <robsherman> … We have the chance to create a level playing field, and compare legal assessment of various jurisdictions.
17:46:37 <BerinSzoka> given the historical lack of meaningful enforcement in Europe, and the very aggressive enforcement actions taken by this FTC, does anyone really think it won't be the FTC that takes the lead on the hard work of defining what level of deidentification is reasonable?
17:46:45 <aleecia_> if it turns out there are problems between EU and US, that's new information and we reopen
17:46:49 <robsherman> … Also need to consider other jurisdictions.
17:46:57 <robsherman> yianni:  So not sure if language works, but need to think about it?
17:46:59 <robsherman> Thomas: Yes.
17:47:00 <BerinSzoka> +q
17:47:00 <aleecia_> Berin, could you kindly knock off the EU baiting?
17:47:17 <rachel_thomas> q+
17:47:18 <robsherman> yianni:  With FTC language, what would be wrong with it, assuming EU perspective works out?
17:47:19 <vincent> BerinSzoka, I'd wait for a couple of month and then answer ;)
17:47:20 <Yianni> q?
17:47:23 <robsherman> ack berinszoka
17:47:49 <aleecia_> In general I'd hesitate about adopting FTC or EU or other "local" bits, but I'll go with math being global. Ideally this works the same everywhere.
17:48:00 <robsherman> berinszoka:  There's no caselaw on this yet.  I'm trying to point out that, whatever anyone thinks about EU vs US, it's pretty likely that the definition of that term is going to happen in US.
17:48:07 <robsherman> … I don't think it's unreasonable to start with that as a baseline.
17:48:08 <robsherman> q+
17:48:08 <aleecia_> John's point is right to consider and in other places I'd agree violently.
17:48:09 <Yianni> q?
17:48:13 <robsherman> ack rachel_thomas
17:48:33 <robsherman> rachel_thomas:  FTC is a good starting point, but it requires looking at the whole document and the impact of changing the definition.
17:48:45 <Yianni> q?
17:48:47 <robsherman> ack robsherman
17:49:01 <aleecia_> I think we need to make decisions and get to drafts, which we will revise many, many times.
17:49:14 <aleecia_> But deadlocking on not making any decisions is getting boring
17:50:46 <MikeZaneis> Agreeing to begin the discussion with the FTC language is good progress that will allow us to iterate further
17:50:47 <Yianni> q?
17:51:58 <robsherman> robsherman:  (1) This group won't get to a place of being able to sign off on FTC definition and go home.  But sounds like the consensus of the group is that we like FTC and DAA definitions as starting points, with the considerations we've discussed, and we need to think through it more.  (2) Don't think we should look at this as an effort to codify all of the privacy laws in the world.  It may be that people have to comply with this standard AND local law[CUT]
17:52:12 <aleecia_> Ok. Do we have specific issues with the FTC text, or a general "we aren't willing to say yes to anything without going back for review" as sort of a general approach to not getting anything done?
17:52:23 <aleecia_> I hear need for review to see how it works with the EU
17:52:37 <aleecia_> Anything else specific? What's the to do list to move forward?
17:52:50 <johnsimpson> what are you saying about transparency?
17:52:51 <robsherman> yianni:  Generally like FTC and DAA language, want to think more.  Okay with some examples as long as not prescriptive.  Admin, tech, physical measures.  Do we agree on these points?
17:52:56 <Yianni> q?
17:53:35 <johnsimpson> q+
17:53:38 <Yianni> q?
17:53:40 <robsherman> … On transparency, significant resistance on providing specific details about security / privacy measures.  Aleecia mentioned we're not going to get agreement here.  So nothing decided there.
17:53:43 <robsherman> ack johnsimpson.
17:53:49 <robsherman> ack johnsimpson
17:53:52 <robsherman> johnsimpson: Agree.
17:54:14 <robsherman> yianni:  On examples, Rachel thought examples weren't the best way to go, but you thought maybe some language could be okay.
17:54:42 <robsherman> rachel_thomas:  I'm not the tech expert on what examples would be most effective, but I agree that defining what's not acceptable - as opposed to what is acceptable - is a better way to go.
17:54:46 <Yianni> q?
17:54:54 <aleecia_> sounds like an action item in the large group
17:54:57 <robsherman> MikeZaneis:  In this F2F, suggest not focusing on non-normative and trying to get to high-level normative agreement.
17:54:58 <aleecia_> for people to write examples
17:55:31 <robsherman> yianni:  Pseudonyms.  Many people said that use of pseudonyms can be compatible with de-identification, if appropriate organizational and physical measures are used.
17:55:37 <johnsimpson> say that again please
17:55:37 <aleecia_> uh, not really
17:55:37 <Yianni> q?
17:55:44 <aleecia_> disagree
17:55:46 <vincent> well I'd disagree with that
17:55:52 <robsherman> … (Repeats per John's request.)
17:56:00 <aleecia_> replacing one GUID with another is not de-id'ed
17:56:12 <Yianni> q?
17:56:13 <johnsimpson> not comfortable with that
17:56:16 <robsherman> … Aleecia, why?
17:56:35 <vincent> again, I'm not sure that organizational measure should be taken into account
17:56:41 <robsherman> aleecia:  If you have something that starts out with a unique identifier and replace it with another unique identifier, you haven't moved toward privacy at all.
17:56:43 <robsherman> q+
17:56:55 <robsherman> … You rotate hashes, so you're not promoting privacy at all.
17:57:02 <robsherman> … No obvious bright line there.
17:57:03 <robsherman> q-
17:57:15 <robsherman> … Would have to do some work to figure out if you've actually de-identified or not.
17:57:30 <robsherman> … This could be part of a useful solution, but I would not make the broad statement you made.
17:57:36 <Yianni> q?
17:57:51 <robsherman> … Using a pseudonym is by itself not enough.
17:57:54 <Yianni> q?
17:58:01 <aleecia_> thanks!
17:58:06 <johnsimpson> when are we back?
17:58:07 <aleecia_> when are we back?
17:58:11 <vincent> thanks! when do we resume?
17:58:12 <Thomas_Schauf> Thomas_Schauf has left #dntd
17:58:17 <Zakim> -Jeff
17:58:18 <Zakim> -Aleecia
17:58:20 <aleecia_> any change from published agenda?
17:58:20 <Yianni> we start back up at 2
17:58:21 <Zakim> -yianni
17:58:22 <aleecia_> thanks!
17:58:35 <Zakim> -johnsimpson
17:58:37 <johnsimpson> johnsimpson has left #dntd
17:58:38 <Zakim> -vincent
17:59:18 <Zakim> -BerinSzoka
17:59:19 <Zakim> Team_(dntd)16:00Z has ended
17:59:19 <Zakim> Attendees were yianni, Jeff, johnsimpson, Dan_Auerbach, BerinSzoka, Aleecia, vincent
17:59:35 <vincent> vincent has left #dntd
18:01:22 <BerinSzoka> BerinSzoka has left #dntd
18:18:59 <fielding> fielding has joined #dntd
18:21:28 <fielding> rrsagent, draft minutes
18:21:28 <RRSAgent> I have made the request to generate http://www.w3.org/2013/02/12-dntd-minutes.html fielding
18:21:47 <fielding> rrsagent, make logs world-visible
18:26:00 <fielding> Meeting: TPWG F2F Breakout Group D
18:27:09 <fielding> rrsagent, draft minutes
18:27:09 <RRSAgent> I have made the request to generate http://www.w3.org/2013/02/12-dntd-minutes.html fielding
18:47:33 <bryan> bryan has left #dntd
19:06:10 <npdoty> npdoty has joined #dntd
19:27:27 <npdoty> rrsagent, make logs public
19:27:32 <npdoty> rrsagent, please draft minutes
19:27:32 <RRSAgent> I have made the request to generate http://www.w3.org/2013/02/12-dntd-minutes.html npdoty
20:00:31 <Zakim> Zakim has left #dntd
20:16:18 <npdoty> npdoty has joined #dntd
20:32:19 <npdoty> npdoty has left #dntd