Live data from Hacker News

The GDPR blog post

medium.com

121–130 of 144 posts

Re: The GDPR blog post

#121
post #26

> this is going to be another ridiculous Cookie Law Given the number of ugly popups I had to click within the last few days, it already is.

I never added this cookie law notice to any of our websites and apps and never had a single problem. We operate in the EU. Pretty small scale. We did nothing for gdpr.

Re: The GDPR blog post

#122
post #81

Earlier quoted context omitted.

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

Couldn't the salt be unique to the requesting account? I would assume that just because a user declined an invitation from one user, they still might want to accept an invitation from a separate user.

Re: The GDPR blog post

#123
post #12

Earlier quoted context omitted.

I don't agree. What's the next step? Will they ban me? Is it my responsibility to reach out to them and tell them I disagree? Or am I just expected to never go to Medium again?

To be GDPR compliant, everything needs to be opt-in (except for the stuff that is critical to functionality). If you refuse to answer their questions, they need to assume that means "no". From this you can see that it's not your responsibility to tell them anything and you can still use their website just fine.

[deleted]

Re: The GDPR blog post

#124
> I would be very wary of a company who claims this legislation is onerous.

... and elsewhere ...

> On the other hand it also was not very hard for us. We are not a creepy company.

> This is not to say that preparing for GDPR didn’t take us 100s of hours. It did.

A company who it didn't affect much, spent 100s of our hours? I think it would reasonable to call that onerous.

The different & fair question would be if time was justified.

Re: The GDPR blog post

#125
post #81

Earlier quoted context omitted.

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

It's really no problem to do this. We're using a variation on this: https://unix.stackexchange.com/questions/158400/etc-shadow-h... . The output of crypt (where the input is an email address) is pretty useless if we did suffer a data breach. They'd have to hash every known email address with that salt in order to figure out who had declined an invite from us.

What is the salt based on?

Re: The GDPR blog post

#126
American entrepreneurs who are proponents of GDPR are experiencing some serious Stockholm Syndrome. Or possibly they're just faking their love for GDPR to virtue signal.

Re: The GDPR blog post

#127
post #97
post #90

Earlier quoted context omitted.

An appropriately tuned bloom filter would probably suffice.

A Bloom filter is an interesting approach, but the problem is that the attacker and you need the same property: to know if an email is in the set. If you could tell set membership with (effectively) perfect accuracy the Bloom filter may improve performance but not privacy. I posted an alternative construction elsewhere in the thread.

The difference is that you may be willing to accept a much higher false-positive rate than your attacker can. This is the same idea behind the old "flip a coin, and then raise your hand if either the coin came up heads or you have [embarrassing problem]" method to statistically count everyone with the embarrassing problem, without disclosing anyone's status with certainty. That's the same property your truncated hash achieves.

A Bloom filter could also be designed accordingly. I'm guessing this post's grandparent was thinking of the filter's natural false-positive rate, or you could add deliberate noise.

Re: The GDPR blog post

#128

Earlier quoted context omitted.

You can't store the e-mail address without consent, and getting consent would probably involve sending a confirmation email.

But providing an email so it can be associated with your profile implies giving consent, as you don't have to do that.

GDPR requires explicit consent if you're using consent as your legal basis for storing that contact email.

Re: The GDPR blog post

#129
post #124

> I would be very wary of a company who claims this legislation is onerous. ... and elsewhere ... > On the other hand it also was not very hard for us. We are not a creepy company. > This is not to say that preparing for GDPR didn’t take us 100s of hours. It did. A company who it didn't affect much, spent 100s of our hours? I think it would reasonable to call that onerous. The different & fair question would be if ti…

Also see:

> We engaged a dedicated GDPR consultant

Re: The GDPR blog post

#130

So, I'm really not trying to start a fight, please read this with curious intent. I personally don't really feel like keeping my email is a violation of my privacy. If they're not "processing" it (that feels like code for "data mining") is this really required? I mean my email address is literally a public means of contacting me. It's kind of fun that they decided to use a one-way hash, but this story doesn't make me…

Keeping your email without a use case is a violation of your privacy. How would you feel if you had to give your home address to the baker to buy a pastry?

I see what you're saying, but I also feel like the two are very different to me.
Post reply on HN