Live data from Hacker News

Debunking the Myth of "Anonymous" Data

eff.org

101–107 of 107 posts

Re: Debunking the Myth of "Anonymous" Data

#101
post #98
post #97

Earlier quoted context omitted.

The analogy isn't that one out of a hundred locks don't work, but the none of the locks work in the face of a skilled attacker that may comprise 1% of the attackers. This isn't saying that locks are worthless, but it is saying that thinking of them as secure is a false confidence. This sort of truth is why there's a saying in the security field that you're at the greatest risk the moment that you think you're secure.…

That’s simply incorrect. Edit: my source for this is that I have been involved with hundreds of data breaches where the EU was satisfied that the privacy controls were sufficient to say that no personal data was compromised.

What part of what I said was incorrect?

Your source doesn't make the case that I was incorrect about any of my assertions. That doesn't mean I'm right, of course, but I don't see how examples of privacy controls successfully protecting data disproves them. There can still be cases where the controls failed.

Re: Debunking the Myth of "Anonymous" Data

#102
post #98

Earlier quoted context omitted.

That’s simply incorrect. Edit: my source for this is that I have been involved with hundreds of data breaches where the EU was satisfied that the privacy controls were sufficient to say that no personal data was compromised.

What part of what I said was incorrect? Your source doesn't make the case that I was incorrect about any of my assertions. That doesn't mean I'm right, of course, but I don't see how examples of privacy controls successfully protecting data disproves them. There can still be cases where the controls failed.

> What part of what I said was incorrect?

All parts of it. You are asserting that a sufficiently skilled attacker can magically overcome all privacy controls. This fundamentally misunderstands how privacy controls work. Don’t make absolute statements, they’re always incorrect (see what I did there?).

When data is compliantly anonymized, the ability to deanonymize it has been irrevocably destroyed. When evaluating privacy controls, you evaluate them against a trusted insider with full access and unlimited time. There are lots of organizations whose controls meet this bar.

Re: Debunking the Myth of "Anonymous" Data

#103
post #96

Earlier quoted context omitted.

> Just come to grips with the fact you're participating in the sale of my (or whoever's) private data. Hope you sleep well! I think it's really sad that the open source community has historically cultivated a culture which doesn't recognize this kind of paranoia as a lack of mental wellness. I think it's because the zealotry comports well with the extreme amount of energy needed to bootstrap the ecosystem into existe…

I'd rather work on building alternatives that respect their users than pay corporations to abuse me, thanks.

I see such attempts as well-intentioned, and while benign, ultimately ineffective. Unless you find a way to make the right way the convenient way, social convergence will be a wind always pushing against you rather than at your back.

Re: Debunking the Myth of "Anonymous" Data

#104

Earlier quoted context omitted.

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

This conversation has me thinking that I could go a step further and replace the hashes with only enough characters to make them unique:

> Baltimore=>0x01a1...1ef7=>01a

> Aaron=>0x17bf...86f1=>17bf

>{"Foo":”Bar"}=>0x19f4...9af2"=>19f

This would create lots of false positives if one attempted to reverse it, but it's still a 1:1 map, so data which satisfies unique and foreign key constraints would still do so after the transformation. As for the utility, it makes it so that you can run the app and see what the user sees--except their data is hidden from you. So suppose the user's complaint is:

> two weeks ago, workflow xyz stopped reaching its final state, but never explicitly changed status to 'failed' so we weren't alerted to the problem.

I can hash "xyz" and get its handle and then go clicking around in he app to see what stands out about it compared to its neighbors. Perhaps there's some should-never-happen scenario like an input is declared but has no value, or there's a cyclic dependency.

I don't need to know the actual names of the depended upon things to identify a cycle in them. The bugs are typically structural, it's not very common that things break only when the string says "Balitmore" and not when it says "1ef7".

Privacy wise, the goal is to be as supportive as possible without having to ask them to share their screen or create a user for us so we can poke around. And when it's a bug, to have something to test with so we can say "It's fixed now." instead of "Try it again, is it fixed now? How about now?"

I'm the third party here, and I'm trying to prevent my users from sharing their users' data with me. Maybe it's not strictly "anonymization" because I'm not sure that this data references people. Remaining unsure is kind of the point.

Re: Debunking the Myth of "Anonymous" Data

#105
post #63

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.

Actually the GDPR "just" requires to protect the data against "reasonably likely" attacks.

« To determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly.

To ascertain whether means are reasonably likely to be used to identify the natural person, account should be taken of all objective factors, such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments. »

https://www.privacy-regulation.eu/en/r26.htm

Re: Debunking the Myth of "Anonymous" Data

#106

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…

In the interest of charitable-ness, can you define "noise" and explain how rudimentary denoising algorithms that have existed since the 1960s can't penetrate it? Time and time again people think they've anonymized data and they're always proven incorrect. Just come to grips with the fact you're participating in the sale of my (or whoever's) private data. Hope you sleep well!

>Just come to grips with the fact you're participating in the sale of my (or whoever's) private data. Hope you sleep well!

What an uncharitable response in that it forecloses on the original commentator even explaining their argument better or clarifying. I mean what? Fuck a bit more honest debate and just jump to pre-assumed moral judgement?

Re: Debunking the Myth of "Anonymous" Data

#107
post #72

Earlier quoted context omitted.

Sorry to break you the news, but your employer is probably selling snake oil. And this is exactly the point of the TFA: > However, in practice, any attempt at de-identification requires removal not only of your identifiable information, but also of information that can identify you when considered in combination with other information known about you. So, anonymization may be well intended and sophisticated, but is o…

I designed our anonymization systems. You clearly have a misunderstanding of the threat model and the treatment methods.

Of course I have a misunderstanding. You only shared some very vague statements. Could you share some insight on your threat model and your envisioned use case?

TFA is obviously referring to the general case where you can't really put arbitrary restrictions to the adversary.

Post reply on HN