RE: de-identification text for Wednesday's call

I'm also curious about Dan's statement about "match the hashed cookie against the stored data."  Can you please explain more about matching the hashed cookie with the non-hashed identifiers?

From: Shane Wiley [mailto:wileys@yahoo-inc.com]
Sent: Tuesday, April 2, 2013 11:03 AM
To: Dan Auerbach; public-tracking@w3.org
Subject: RE: de-identification text for Wednesday's call

Dan,

Once the one-way hash is applied (and other elements of record appropriately cleansed) the data is moved to a system that is not allowed to be accessed externally.  Its these operational and administrative controls that are essential to ensure de-identified data is not re-identified at some later time.  I believe you're looking only at the technical merits which is only seeing a small portion of the overall solution.

- Shane

From: Dan Auerbach [mailto:dan@eff.org]
Sent: Tuesday, April 02, 2013 10:59 AM
To: public-tracking@w3.org<mailto:public-tracking@w3.org>
Subject: Re: de-identification text for Wednesday's call

On 04/02/2013 08:50 AM, Shane Wiley wrote:
once the one-way hash function has been applied the data is never again able to be accessed in real-time to modify the user's experience.
I think I'm confused, can you explain this more? How is this possible? If you are just hashing a cookie string, your web server receives a request that includes a cookie string, you hash that cookie string (which is in incredibly fast operation), match the hashed cookie against the stored data, and return personalized results.

Or are you salting the hash differently for every request, or combining the cookie with an ephemeral piece of data (the timestamp) before hashing and then throwing away the timestamp?

Thanks for clarifying, apologies if I'm just being dense.

Dan


--

Dan Auerbach

Staff Technologist

Electronic Frontier Foundation

dan@eff.org<mailto:dan@eff.org>

415 436 9333 x134

Received on Tuesday, 2 April 2013 18:12:08 UTC