"De-identified data isn't. Either it's not de-identified, or it's not data anymore."
-- Cynthia Dwork, one of the invertors of Differential Privacy, Knuth Prize and Gödel Prize winner.
Debunking the Myth of "Anonymous" Data
51–60 of 107 posts
Re: Debunking the Myth of "Anonymous" Data
#52I work for a data privacy startup, and this article unfortunately groups all forms of anonymization together. It is specifically criticizing forms of anonymization that only treat direct identifiers like names, addresses, and phone numbers. That is usually referred to as "pseudonymization", and they are correct to point out that an only moderately sophisticated attacker can still link people in the dataset using comb…
I'm usually the first to defend the EFF but I agree that they've gone a bit far here. The anonymization script which I wrote for my company just replaces every string in the customer's database with a cryptographic hash--except a list of strings like "failed" and "success". So unless your city is named "success", it's going to be missing from the dataset. It's a bit bewildering to actually run the app in this mode, b…
You've answered your own questions and kind of defeated your own point here:
> Meanwhile, somebody looking to harm the user would need to already know quite a lot about that user before they could make any use out of such a thing.
The one thing I see EFF did wrong in this article is, they picked a bad quote to start with. That line from Matt Blaze, it's almost a pure tautology. There's a better line (though I don't know who to credit with it - I picked it up on HN some time ago): there is no such thing as "anonymized data", there's only "anonymized until correlated with enough other datasets".
You say "somebody" would need to already know a lot about the user to make use of your database. But from my perspective - perspective of the user - that "somebody" could just as well be your company. Or your customer buying that data from you... and buying similar data from other companies.
Re: Debunking the Myth of "Anonymous" Data
#53There's anonymizing data so that creepy guy two floors down can't stalk the barista across the street, and there's anonymizing data so that you can publish it to the world.
Barely even comparable.
Re: Debunking the Myth of "Anonymous" Data
#54Earlier quoted context omitted.
I'm usually the first to defend the EFF but I agree that they've gone a bit far here. The anonymization script which I wrote for my company just replaces every string in the customer's database with a cryptographic hash--except a list of strings like "failed" and "success". So unless your city is named "success", it's going to be missing from the dataset. It's a bit bewildering to actually run the app in this mode, b…
> replaces every string in the customer's database with a cryptographic hash > So unless your city is named "success", it's going to be missing from the dataset. You've made the typical mistake of thinking that just because you've made it harder , you've also made it anonymous. For instance, you might have replaced "Chicago" with 9cfa1e69f507d007a516eb3e9f5074e2, but if for instance a lot of people with that tokenise…
Let’s at least grant the benefit of the doubt, that the poster knew to salt the hash. We can take it as given that incompetence makes for poor anonymization.
Your example of “transactions in Chicago” is much more salient; there’s clearly a cat-and-mouse dynamic where data can be de-anonymized, especially if the dataset is public. How much that will actually be possible will be specific to the data in question; but the risk is non-zero. There’s certainly a case that no amount of obfuscation is sufficient if a user has not explicitly consented to their data being used this way.
Re: Debunking the Myth of "Anonymous" Data
#55I work for a data privacy startup, and this article unfortunately groups all forms of anonymization together. It is specifically criticizing forms of anonymization that only treat direct identifiers like names, addresses, and phone numbers. That is usually referred to as "pseudonymization", and they are correct to point out that an only moderately sophisticated attacker can still link people in the dataset using comb…
> *There is always a tradeoff between privacy and utility. The only way to achieve 100% private data is 100% noise, but the privacy-utility tradeoff curve isn't linear, and you can still achieve very good utility and very good privacy in many cases, especially with the best tools. Methods are also improving over time, reducing the impact of the tradeoff. This is the crux of the problem. In every situation where I've…
My experience is no different and in fact it’s hard to convince anyone to treat indirect identifiers at all. Everyone wants the bare minimum, which is unfortunate, but understandable for someone trying to run a business. All of our current customers are only using their data internally and anonymizing to protect identities as that data is shared across other internal groups, mostly for testing and analysis. Even protecting only direct identifiers is far more responsible than the vast majority of businesses, though we push for indirect treatment.
If you treat indirect identifiers with our system, the minimum level of anonymization would ensure that there are always a minimum of two matching combinations of indirect identifiers, i.e. k=2, for every record in the dataset. This is far from foolproof for preventing data leakage, but it does prevent singling out and provides a lot of protection in the case of breach.
Re: Debunking the Myth of "Anonymous" Data
#56Great article putting all the relevant content in one place. Does anyone know of any de-anonymization services? The startup I am working at is privacy focused and we are looking for a way to demonstrate why you need an additional layer to protect and compartmentalize. Short of us buying up data in bulk and then doing the de-anonymization in-house I am not seeing an easy way to do this. Or even an advertised partner,…
I just realized you wrote “de-anonymization”. We don’t do that, but we do a risk analysis that simulates an attack, making some pessimistic assumptions about what data an attacker may have for linkage, to estimate how risky data is to share, essentially as a benchmark. TLDR; more unique combinations of quasi-identifiers make data more susceptible to a linkage attack. We also pitch our system as a risk analysis only tool, though no one is using it for that currently. If you’re interested in methods, I’d recommend El Emam’s book, “Guide to the De-Identification of Personal Health Information”, which covers a lot in detail. Our attack simulation is based on his work.
Re: Debunking the Myth of "Anonymous" Data
#57Earlier quoted context omitted.
I'm usually the first to defend the EFF but I agree that they've gone a bit far here. The anonymization script which I wrote for my company just replaces every string in the customer's database with a cryptographic hash--except a list of strings like "failed" and "success". So unless your city is named "success", it's going to be missing from the dataset. It's a bit bewildering to actually run the app in this mode, b…
> replaces every string in the customer's database with a cryptographic hash > So unless your city is named "success", it's going to be missing from the dataset. You've made the typical mistake of thinking that just because you've made it harder , you've also made it anonymous. For instance, you might have replaced "Chicago" with 9cfa1e69f507d007a516eb3e9f5074e2, but if for instance a lot of people with that tokenise…
I think of this as a graph of interconnected data and metadata. Unless the entire graph is anonymized, it's not really anonymized.
Deducing relationships between metadata elements (city field, and purchase store) ends up being the tricky part, and highly domain specific.
Hashes with salts make it a bit harder too.Re: Debunking the Myth of "Anonymous" Data
#58I work for a data privacy startup, and this article unfortunately groups all forms of anonymization together. It is specifically criticizing forms of anonymization that only treat direct identifiers like names, addresses, and phone numbers. That is usually referred to as "pseudonymization", and they are correct to point out that an only moderately sophisticated attacker can still link people in the dataset using comb…
I'm usually the first to defend the EFF but I agree that they've gone a bit far here. The anonymization script which I wrote for my company just replaces every string in the customer's database with a cryptographic hash--except a list of strings like "failed" and "success". So unless your city is named "success", it's going to be missing from the dataset. It's a bit bewildering to actually run the app in this mode, b…
> replaces every string in the customer's database with a cryptographic hash [..] So unless your city is named "success", it's going to be missing from the dataset.
I'm not sure I understand. Wouldn't it be trivial to hash the name of every known city, thereby reversing your cryptographic hash? As is done for passwords, only with a much smaller space of possibilities.
Re: Debunking the Myth of "Anonymous" Data
#59Earlier quoted context omitted.
I'm usually the first to defend the EFF but I agree that they've gone a bit far here. The anonymization script which I wrote for my company just replaces every string in the customer's database with a cryptographic hash--except a list of strings like "failed" and "success". So unless your city is named "success", it's going to be missing from the dataset. It's a bit bewildering to actually run the app in this mode, b…
You've answered your own questions and kind of defeated your own point here: > Meanwhile, somebody looking to harm the user would need to already know quite a lot about that user before they could make any use out of such a thing. The one thing I see EFF did wrong in this article is, they picked a bad quote to start with. That line from Matt Blaze, it's almost a pure tautology. There's a better line (though I don't k…
> You say "somebody" would need to already know a lot about the user to make use of your database. But from my perspective - perspective of the user - that "somebody" could just as well be your company
Well yes, noticing problems in these databases and providing consulting towards their mitigation (ideally before the pain shows up) is more or less what we're selling. Some degree of analysis must remain possible because otherwise it would be unclear what the user is paying us for.
My point is just that different situations call for different privacy postures. "Anonymization = Untrustworthy" glosses over this in a way that doesn't help us find ways to improve the situation.
Re: Debunking the Myth of "Anonymous" Data
#60Earlier quoted context omitted.
I'm usually the first to defend the EFF but I agree that they've gone a bit far here. The anonymization script which I wrote for my company just replaces every string in the customer's database with a cryptographic hash--except a list of strings like "failed" and "success". So unless your city is named "success", it's going to be missing from the dataset. It's a bit bewildering to actually run the app in this mode, b…
> replaces every string in the customer's database with a cryptographic hash [..] So unless your city is named "success", it's going to be missing from the dataset. I'm not sure I understand. Wouldn't it be trivial to hash the name of every known city, thereby reversing your cryptographic hash? As is done for passwords, only with a much smaller space of possibilities.
[deleted]