Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Debunking the Myth of "Anonymous" Data

eff.org

Post reply on HN
Print view View original

61–70 of 107 posts

Re: Debunking the Myth of "Anonymous" Data

#61

Post by __MatrixMan__ »

SenAnder wrote: post #58
__MatrixMan__ wrote: post #36

Earlier 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.

They are salted hashes. Also, I chose city out of thin air. Realistically the column names are generic, "output", "input" things like that. So you'd also have to guess that this particular user is putting city data in their outputs before you'd be able to run the "known cities" attack.

Re: Debunking the Myth of "Anonymous" Data

#62

Post by jmatthews »

I like to make an appearance in threads in this domain and just say, yeah, it's not just possible but "fun" to put the puzzle pieces together.

It is a very tough problem to solve. Especially when you consider the richness of the datasets you use to put the pieces together.

In my experience the only effective means is to poison the data, in addition to the common sense steps mentioned here.

Poisoning a dataset means seeding a wide variety of the datasets you use to discover PII with fictional look alikes that resist debunking.

Additionally you can poison the core set if you are very clever about it.

Re: Debunking the Myth of "Anonymous" Data

#63

Post by lsh123 »

As others pointed out, the article mixes a lot of things together. EU (GDPR) has very specific and very hard to meet anonymization bar (tldr; it requires anonymization to be at the level where it’s mathematically improbable to de-anonymize the user). None of the “anonymization” examples in the article would pass this EU bar.

Re: Debunking the Myth of "Anonymous" Data

#64

Post by lsh123 »

willseth wrote: post #16

I 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…

Re adding noise: https://en.wikipedia.org/wiki/Differential_privacy

Re: Debunking the Myth of "Anonymous" Data

#66

Post by orbital-decay »

jruohonen wrote: post #2

A good popular take, but they, either intentionally or out of ignorance, omit newer, proven techniques like differential privacy.

Differential privacy does not anonymize your data. It's a (mathematically solid) instrument to make it coarse enough to only give up the part you want.

The EFF is completely correct in their assessment - there's no way to make your data anonymous and usable by the third party at the same time. The root issue lies elsewhere.

There's FHE, which does allow your data to be processed without accessing it, but it has prohibitive compute requirements and isn't practical for most purposes. I'm not sure if it allows the data to be usable enough without revealing it, either.

Re: Debunking the Myth of "Anonymous" Data

#67

Post by SenAnder »

__MatrixMan__ wrote: post #61
SenAnder wrote: post #58

Earlier quoted context omitted.

> 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.

They are salted hashes. Also, I chose city out of thin air. Realistically the column names are generic, "output", "input" things like that. So you'd also have to guess that this particular user is putting city data in their outputs before you'd be able to run the "known cities" attack.

Yes, password cracking works on salted hashes too. And the way you now describe it, with the entries in every column being hashed, and the column names themselves being meaningless*, I'm confused what value such a database has for anyone. They're just columns of random data, and the analyst doesn't even know what the data represents?

*And presumably, somehow, there being no way to recover this meaning. E.g. if an attacker is reversing hashes, they could try several sources of guesses - city names, country names, common first and last names in several languages, heights and weights in metric and imperial in the human range, valid phone numbers, IPv4 addresses, dates, blood type, license plate and post numbers or entire addresses, e-mail addresses if the attacker has a list of known-valid emails... all of these, and I'm sure many others that I forgot, are sufficiently small that they can be brute-force guessed by simply trying all possibilities, so no matter how generic the name of a column is, if it contains any of this data, the hashing can be reversed.

Re: Debunking the Myth of "Anonymous" Data

#68

Post by JohnFen »

__MatrixMan__ wrote: post #59
TeMPOraL wrote: post #52

Earlier quoted context omitted.

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 becau…

> My point is just that different situations call for different privacy postures.

True. Privacy is a special case of security, and it's only useful to talk about security in terms of what threats are of concern.

> "Anonymization = Untrustworthy" glosses over this in a way that doesn't help us find ways to improve the situation.

If your concern is to be as anonymous as possible, then "Anonymization = untrustworthy" is not an unreasonable stance. The only way I know of that data can be collected and handled in an anonymous way is to aggregate the collected data immediately and discard all individualized data.

Replacing data with something like a hash is useful in many ways, but there are many things it isn't that useful with.

Re: Debunking the Myth of "Anonymous" Data

#69

Post by mindslight »

lukifer wrote: post #54
ralferoo wrote: post #43

Earlier quoted context omitted.

> 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 th…

> 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.

Actually let's not, because adding salting doesn't actually get it right either. Rather it's just another easily-broken system that is only good enough to fool its own designer. It's still trivial to run through a list of the most common city names, and recover nearly all of the entries. And if there is just a single "salt" per DB, which would be necessary for the apparent requirement that matching city names stay matching, even cycling through all combinations of letters is nearly practical. There just isn't enough starting entropy to make hashing meaningful.

Re: Debunking the Myth of "Anonymous" Data

#70

Post by rendaw »

willseth wrote: post #16

I 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…

The article suggests but does not explicitly describe adding noise, but it doesn't matter because the conclusion is the same:

> There is always a tradeoff between privacy and utility. The only way to achieve 100% private data is 100% noise

The point is that the people whose data is being "protected" rarely have a say that their data is in the data set in the first place, and to what level their data is noised when it is.

Post reply on HN