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

The GDPR blog post

medium.com

Post reply on HN
Print view View original

81–90 of 144 posts

Re: The GDPR blog post

#81

Post by comex »

TeMPOraL wrote: post #65
comex wrote: post #60

Earlier quoted context omitted.

Or even if ShadyAdtechCo just knows what the hashing function is, and has a list of plaintext email addresses to test against – perhaps obtained from one of the datasets they're joining against, or even from crawling the web.

Hashing should be done with salt for precisely that reason.

If you mean a static salt, that could help mitigate against hacks (if the attacker has access to the database but not the code), but where adtech is concerned it's probably more realistic to assume that the datasets they're using were disclosed willingly. If you mean using a different salt for each address, that could work for some use cases, but it wouldn't work for the use case described in the blog post, since Touch Surgery needs to be able to lookup whether a given address is in the database (to see whether they've previously declined an invitation).

Re: The GDPR blog post

#82

Post by frereubu »

megaman22 wrote: post #59
TeMPOraL wrote: post #40

Earlier quoted context omitted.

The problem is identification of physical persons. Your e-mail is public, but it also identifies you as a person. This is important, because it allows for correlating different data sets. Touch Surgery sounds like a honest company, so for them this was just some extra burden. But the same law prevents ShadyAdtechCo from getting datasets from several companies and joining them on e-mail column to build a profile of yo…

An email address identifies an email address, not a person. More than a few times I've signed up to newsletters with a distribution list address, that maps to n number of actual people behind the group, who may or may not be fixed members of that group. You could track c_sharp_enthusiasts@myCompany.com, but that is not identifying a person.

In many cases it will identify a person. I have two email addresses, a personal one and a home one, and I don't use any others. In my case this absolutely will identify me, and I would argue that in the vast majority of case this will be true as well. You're unusual relative to the general population in using distribution list addresses, and they have to start somewhere. I would also argue that this is exactly the piece of information that is most commonly used to merge datasets, and that's probably why the legislation includes it.

Re: The GDPR blog post

#83

Post by bcoates »

krageon wrote: post #5
meta_AU wrote: post #2

Is there not any issue with having a hashed version of the email, given the entropy of an email address is quite small?

It cannot be reversed without a significant amount of effort (really, even when you say the "entropy is quite small" it's not actually as small as you would think) and is therefore probably reasonable. Worst case a regulating body will tell you that no, they do not think "this will take 1-10 years to reverse" is quite good enough and then you can work with them on a solution that would be good enough.

Minutes to days to reverse almost the whole list, depending on budget. It's not a real obstruction except to casual snooping.

Re: The GDPR blog post

#84

Post by talkingtab »

lvh wrote: post #56
hvidgaard wrote: post #10

Earlier quoted context omitted.

Maybe, but they have a good reason to keep that data, and they even go out of their way to "hide it" the best they can using a one-way function. To save the information that a certain email address has explicitly withdrawn consent, they need to store it. The alternative is to send out a new email the next time someone adds then. I think the interpretation of GDPR this particular instance of information storing is sti…

You're right, but there are safer constructions to do this. Maybe this kind of knowledge will get more popular now that GDPR is mandating it :) Active concern for me: GDPR will promote a bunch more homegrown looks-fine-but-actually-busted crypto schemes. I don't think GDPR will be used to enforce that even in the case of breach, and I'm not sure it should -- I think we should make better schemes available instead.

What is the 'safer construction' to do this? I'm looking for ideas and trying to solve a problem. My understanding of the GDPR, which is very basic, supports the view that hashing email addresses is at least questionable. On the other hand, if an email list is a core function, de-spamming seems valid.

Re: The GDPR blog post

#85

Post by hvidgaard »

lvh wrote: post #56
hvidgaard wrote: post #10

Earlier quoted context omitted.

Maybe, but they have a good reason to keep that data, and they even go out of their way to "hide it" the best they can using a one-way function. To save the information that a certain email address has explicitly withdrawn consent, they need to store it. The alternative is to send out a new email the next time someone adds then. I think the interpretation of GDPR this particular instance of information storing is sti…

You're right, but there are safer constructions to do this. Maybe this kind of knowledge will get more popular now that GDPR is mandating it :) Active concern for me: GDPR will promote a bunch more homegrown looks-fine-but-actually-busted crypto schemes. I don't think GDPR will be used to enforce that even in the case of breach, and I'm not sure it should -- I think we should make better schemes available instead.

Using a hash function for this is about as good as it's going to be. If we accept the conjecture of the existence of one-way functions, and use a cryptographic sound one-way function and implementation, it's provably the best we can do.

Re: The GDPR blog post

#86

Post by krageon »

pferde wrote: post #50
krageon wrote: post #8

Earlier quoted context omitted.

The most hilarious part of that is that you really don't need to. I've added a blacklist for everything (first party JS, styling, images) on medium.com and everything continues to work just fine. I don't remember specifically why I did that, but it's probably a dark pattern (such as a modal that pops up after one paragraph of reading) that annoyed me in the past.

Hm, they must have changed how the site works. A while ago, I decided to simply skip any medium.com link posted to HN, because a) it was a crap experience reading on mobile, b) it was a crap experience reading with javascript disabled and c) with javascript enabled, the site was too annoying

When I say "it works fine" I mean "the text is on the page and in a reasonable font". There is a huge amount of wasted space in terms of crap content (banners, etc - all mangled because there is no JS) there, which would be annoying on mobile. This experience (in my mind) competes with websites that will not show the content at all without JS, which is not a high bar.

Re: The GDPR blog post

#87

Post by tomelders »

I had a recruiter call me up with what I suspect was a made up role. At the end of the call he casually dropped in the line "ok, well, is it ok if I get back in touch when something more suitable comes in?"

It was conspicuous. I asked is he'd asked me that because of GDPR. He said yes. I said no.

Re: The GDPR blog post

#88

Post by tallanvor »

meta_AU wrote: post #2

Is there not any issue with having a hashed version of the email, given the entropy of an email address is quite small?

I honestly can't see this being something that would ever result in enforcement action.

They have a legitimate business interest in not spamming someone if people try to sign you up multiple times, and since the email address is hashed, all they can use it for is to determine if they've sent you an invite before (and potentially when they did so, or when you declined the invitation).

Maybe they could get in trouble if they also retain information on who is trying to send you invites and creating a graph and a shadow profile based on this type of information, but it sounds pretty clear that this isn't something they're doing or are interested in doing.

Re: The GDPR blog post

#89

Post by krageon »

bcoates wrote: post #83
krageon wrote: post #5

Earlier quoted context omitted.

It cannot be reversed without a significant amount of effort (really, even when you say the "entropy is quite small" it's not actually as small as you would think) and is therefore probably reasonable. Worst case a regulating body will tell you that no, they do not think "this will take 1-10 years to reverse" is quite good enough and then you can work with them on a solution that would be good enough.

Minutes to days to reverse almost the whole list, depending on budget. It's not a real obstruction except to casual snooping.

Could you walk me through how you come to that conclusion? I admit my estimate was very ballpark, but "minutes" seems so wildly out of line with what I think I must be making a mistake somewhere.

Re: The GDPR blog post

#90

Post by zwily »

talkingtab wrote: post #84
lvh wrote: post #56

Earlier quoted context omitted.

You're right, but there are safer constructions to do this. Maybe this kind of knowledge will get more popular now that GDPR is mandating it :) Active concern for me: GDPR will promote a bunch more homegrown looks-fine-but-actually-busted crypto schemes. I don't think GDPR will be used to enforce that even in the case of breach, and I'm not sure it should -- I think we should make better schemes available instead.

What is the 'safer construction' to do this? I'm looking for ideas and trying to solve a problem. My understanding of the GDPR, which is very basic, supports the view that hashing email addresses is at least questionable. On the other hand, if an email list is a core function, de-spamming seems valid.

An appropriately tuned bloom filter would probably suffice.
Post reply on HN