- From: Shane Wiley <wileys@yahoo-inc.com>
- Date: Tue, 16 Oct 2012 23:18:11 -0700
- To: Ed Felten <ed@felten.com>, "public-tracking@w3.org" <public-tracking@w3.org>
- Message-ID: <63294A1959410048A33AEE161379C8027480CCD9CF@SP2-EX07VS02.ds.corp.yahoo.com>
Ed, Here are the direct responses to your earlier questions on Unlinkability: (A) Why does the definition talk about a process of making data unlinkable, instead of directly defining what it means for data to be unlinkable? Some data needs to be processed to make it unlinkable, but some data is unlinkable from the start. The definition should speak to both, even though unlinkable-from-the-start data hasn't gone through any kind of process. Suppose FirstCorp collects data X; SecondCorp collects X+Y but then runs a process that discards Y to leave it with only X; and ThirdCorp collects X+Y+Z but then minimizes away Y+Z to end up with X. Shouldn't these three datasets be treated the same--because they are the same X--despite having been through different processes, or no process at all? [I believe the definition is subsumed in process (breaking the link with production systems) and is already called out.] (B) Why "commercially reasonable" rather than just "reasonable"? The term "reasonable" already takes into account all relevant factors. Can somebody give an example of something that would qualify as "commercially reasonable" but not "reasonable", or vice versa? If not, "commercially" only makes the definition harder to understand. [Commercially reasonable takes into account more considerations of what in reasonable to "any person" and what would be reasonable to consider a company to be able to perform. As this is fairly standard language in contracts it feels appropriate to use this here as well.] (C) "there is confidence" seems to raise two questions. First, who is it that needs to be confident? Second, can the confidence be just an unsupported gut feeling of optimism, or does there need to be some valid reason for confidence? Presumably the intent is that the party holding the data has justified confidence that the data cannot be linked, but if so it might be better to spell that out. [Confidence - the company representing that they have achieved unlinkabliity. I'm okay with adding some degree of diligence be required here versus "unsupported gut feeling of optimism".] (D) Why "it contains information which could not be linked" rather than the simpler "it could not be linked"? Do the extra words add any meaning? [I believe both options work but the "contains information" highlights issues like URL details better than the simpler form you've offered.] (E) What does "in a production environment" add? If the goal is to rule out results demonstrated in a research environment, I doubt this language would accomplish that goal, because all of the re-identification research I know of required less than a production environment. If the goal is to rule out linking approaches that aren't at all practical, some other language would probably be better. [The goal is to prohibit production use of retained data. This is of course a "use based" approach to solving the issue here versus a "collection based" approach. My hope is that this approach finds the sweet spot between proportionally reducing consumer privacy risks and at the same time allowing the data to be used for anonymous/aggregated reporting/analytics/research. Anonymization/aggregation approaches discussed to data such as K-Anonymity destroy a considerable amount of value in data - as well as arbitrarily force non-DNT data to also be funneled into these approaches for consistency in analytics.] - Shane From: Ed Felten [mailto:ed@felten.com] Sent: Wednesday, October 03, 2012 8:20 AM To: Shane Wiley Subject: re: my questions Sorry, I don't see a reply from you that addresses my questions specifically. You did say what the general goal of your proposal, but I don't think you addressed my specific questions. If I missed something in my quick review of your messages in the thread--which is quite possible--please point me to the right place.
Received on Wednesday, 17 October 2012 06:18:48 UTC