> 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.
The GDPR blog post
121–130 of 144 posts
Re: The GDPR blog post
#122Earlier 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…
Re: The GDPR blog post
#123Earlier 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.
Re: The GDPR blog post
#124... 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
#125Earlier 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.
Re: The GDPR blog post
#126Re: The GDPR blog post
#127Earlier 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.
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
#128Earlier 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.
Re: The GDPR blog post
#129> 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…
> We engaged a dedicated GDPR consultant
Re: The GDPR blog post
#130So, 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?