131–140 of 144 posts
Earlier quoted context omitted.
In theory, if you don't reply, all these companies should stop using your data and quite likely delete it. Sounds like improving safety for me.
It sounds pretty tedious to sift through 300+ emails to find everyone you want to keep using your data and go through whatever process they have for replying.
Earlier quoted context omitted.
Why is it a problem that you have to agree to be monetized to read a stupid blog post? If you don't like those terms, go read something else. If you refuse their terms, it seems obvious to me that they should be able to refuse to serve you. Maybe I'm missing something here, but this sounds like asking for a free lunch.
> Why is it a problem that you have to agree to be monetized to read a stupid blog post? Do you want my opinion or what the gdpr says? My opinion is that my data is not a commodity exchange. We (I) usually use money for that. The gdpr says "When assessing whether consent is freely given, utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is condi…
So, you decline the exchange (as you did).
Why should the law forbid me from making such exchange, if I want to?
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.
> 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…
At $dayjob we are at hundreds of thousands of dollars in staff time and legal fees (mostly updating and reviewing existing contracts). We don’t do anything shady with user data, and already have a robust data security program due to our industry.
A family member’s small business which packages meats for the grocery is similarly burdened to the tune of hundreds of thousands.
That’s a huge waste repeated millions of times over around the world. They could have just targeted this at the big web companies and Adtech firms with some simple qualifiers. This law isn’t really much good for consumers, but it’s very good for lawyers.
> 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…
100 hours is 12.5 days. That is not much to protect your users data.
Earlier quoted context omitted.
It sounds pretty tedious to sift through 300+ emails to find everyone you want to keep using your data and go through whatever process they have for replying.
Why do you want them to keep using your data?
Earlier quoted context omitted.
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
The thread model is an adversary that gets unlimited access to the values stored for this purpose, and knows the function used to compute it. He wants to check if a given email is in the set. One-way functions is provably the best way to be able to ask yes/no to the question if this email is in the set with no false answers. I have not said anything about using computationally expensive one-way functions because that does not matter if the function takes 10 seconds to compute. He already knows what emails he wants to check.
Earlier quoted context omitted.
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…
Is there not any issue with having a hashed version of the email, given the entropy of an email address is quite small?
Yes. They don't quite define how the hash works in the post, but assuming it's something like SHA256(email), that's easy to enumerate. There are ways to do this better. Let's say that it's 1 party and you're trying to figure out if you've seen en email address before. (That's the case in the article, there are also schemes where you and another entity can figure out if you both saw any email addresses -- but that's n…
That particular part is assuming security through not knowing the implementation of the security models components, aka. security through obscurity. Rule no. 1 in security, always assume that the adversary knows exactly how everything is implemented and can do that for himself.
Earlier quoted context omitted.
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…
If had a service where I wanted people to use it and only remember explicitly opt-out, I wouldn't want any false positives to the "have already opted out" question.
This raises fun questions of what it means to disclose a fact, when you're disclosing it probabilistically. Let's say that you tell me the yes/no answer to a question you consider private. I then generate a uniform random number X on [0, 1], and disclose (("you told me yes") || (X >= a)) for some agreed constant a.
If a = 1, then I've almost surely just disclosed your secret. If a = 0, then I've almost surely disclosed nothing. At what value of a do you start to care? That's a really messy question, depending on the social consequences of the information being disclosed (what fraction of innocent candidates would you reject to make sure your child's tutor isn't on the list of clients of a psychologist known for treating pedophiles?), and the other public information about you and about my population that an attacker can fuse to make a stronger estimate.
I don't think privacy-through-false-positives is a terribly effective tool. It's just the only possible tool for creating privacy when your rule is public (whether deliberately or after a breach)--so it's interesting to think about places where it could have some benefit.