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

91–100 of 144 posts

Re: The GDPR blog post

#91

Post by frockington »

Symbiote wrote: post #30
TeMPOraL wrote: post #23

Earlier quoted context omitted.

Wow. That's the funniest thing I've seen this week. Beats the schadenfreude I'm having with some of the IoT lightbulbs no longer working for EU customers - a problem which actually impacted a friend of mine. See: https://twitter.com/internetofshit/status/999619364541394944 . EDIT: 2 friends now. I wonder how many more bought those lightbulbs...

Anyone who bought these lightbulbs should return them to the retailer for a full refund.

That'd be an entertaining help desk conversation. "No the product is still functional, but my country made it too much of a hassle for them to operate in my region"

Re: The GDPR blog post

#92

Post by svalorzen »

dmortin wrote: post #41
y0ghur7_xxx wrote: post #39

Earlier quoted context omitted.

> They can't, but they can, for example, ask for a fee to read the article. They don't deny you reading it, but they don't have to give it to you for free either. Of course they can charge a fee. They should. > Either you share your data, so they can make money to operate the site, or you don't, but then the content is not free. No. My data is not a commodity exchange. The GDPR makes that VERY clear. I can not pay wi…

You can pay with your data if you consent to it. It's your data, your choice. But if you don't consent then prepare your credit card for payment. Most people then will choose the free version.

As y0ghur7_xxx is saying, you cannot pay with your data, just as you cannot take a loan with an interest rate of 1000%, since that would be usury. Even if you signed a contract agreeing to such terms, they don't count as they are not legal.

Contracts don't make laws. Laws make laws. You cannot pay with your data.

Re: The GDPR blog post

#93

Post by dvfjsdhgfv »

baq wrote: post #6

I got a few dozen gdpr emails today, some from companies I didn't know existed. This law is a fantastic development for end users/consumers.

They're mostly incompetent: https://www.theguardian.com/technology/2018/may/21/gdpr-emai...

The rest knows well that they got your address without your consent and try to get this consent from you now so that they can legally keep your data.

Re: The GDPR blog post

#94

Post by lvh »

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.

I posted a comment with an alternative construction plus rationale: https://news.ycombinator.com/item?id=17153329

Re: The GDPR blog post

#95

Post by lvh »

hvidgaard wrote: post #85
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.

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.

That's not provably the case at all. We can absolutely do better, for reasons the root of this thread raises. If that were true, why isn't SHA256 the state of the art in password storage? Reason: the input space is small enough to enumerate.

I posted a comment with an alternative construction plus rationale: https://news.ycombinator.com/item?id=17153329

Re: The GDPR blog post

#96

Post by retSava »

Symbiote wrote: post #30
TeMPOraL wrote: post #23

Earlier quoted context omitted.

Wow. That's the funniest thing I've seen this week. Beats the schadenfreude I'm having with some of the IoT lightbulbs no longer working for EU customers - a problem which actually impacted a friend of mine. See: https://twitter.com/internetofshit/status/999619364541394944 . EDIT: 2 friends now. I wonder how many more bought those lightbulbs...

Anyone who bought these lightbulbs should return them to the retailer for a full refund.

The yeelights are typically bought on eg Aliexpress. I have mine with the local network developer functionality enabled, here's to hoping they will still work with that at least.

Re: The GDPR blog post

#97

Post by lvh »

zwily wrote: post #90
talkingtab wrote: post #84

Earlier quoted context omitted.

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.

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.

Re: The GDPR blog post

#99

Post by merijnv »

inopinatus wrote: post #32
TeMPOraL wrote: post #3

A popup (probably what used to be cookie warning) on Medium says: > Medium uses browser cookies to give you the best possible experience. To make Medium work, we log user data and share it with processors. To use Medium, you must agree to our Privacy Policy. I must agree to logging user data and sharing it with processors? EDIT: come to think of it, it might be a new, GDPR-specific, dark pattern. I can use the site w…

Isn't that the quid pro quo, though? I don't feel obliged to accept their shitty privacy policy, and in return they are not obliged to serve me their often equally shitty content.

> I don't feel obliged to accept their shitty privacy policy, and in return they are not obliged to serve me their often equally shitty content.

Yes and no. Yes, in the sense that you can argue that. No, in the sense that the GDPR just says "no, you cannot ask people to pay with personal information". So either they must show me the article even if I opt-out of giving my information. Or they must make reading their article conditional upon something else (say, paying them). They CANNOT make it conditional upon my consent to use my personal data, because that's just coercing me into clicking "yes", which is exactly what GDPR is supposed to curb.

Re: The GDPR blog post

#100

Post by Waterluvian »

baq wrote: post #6

I got a few dozen gdpr emails today, some from companies I didn't know existed. This law is a fantastic development for end users/consumers.

I got so many emails from services someone accidentally used my email to sign me up for. Very eye opening.
Post reply on HN