4 ms·

I’ve heard this claim, but they could use some sort of bloom filter pr cryptographic hashing to block profiles that contain previously-removed records. There c

by hedora 2y ago

I’ve heard this claim, but they could use some sort of bloom filter pr cryptographic hashing to block profiles that contain previously-removed records. There could also be a shared, trusted opt-out service that accepted information and returned a boolean saying “opt-out” or “opt-in”. Ideally, it’d return “opt-out” in the no-information case.

lazide 2y ago
Yup, it would be trivial to create a one way hash of various attributes to perma ‘opt out’ someone. But how would they keep making money that way?
zo1 2y ago
So for a perfect match they'd need to have some sort of unique identifier that's present in the first set of data you ask them to remove, as well as being present in any subsequent "acquisitions" or "scrapes" of your data. If these devs that scrape/dump/collate all this info are anything like the ones I've seen, and they're functioning in countries like the US and UK whereby you don't have individual identifiers that are pretty unique, then I'd say the chance of them being able to get such a "unique" key on you to remove you perpetually, is next to impossible. And if it's even close to being "hard", they'll not even bother. Doubley-so if this service/people/data is anything like the credit-score companies, which are notoriously bad at data de duplication and sanitation. Likewise, if you want them to do some sort of removal using things other than a unique identifier, then you have to have some sort of function that determines closeness between the two records. From what I've heard, places like Interpol, countries' border-control and police agencies usually use name, surname and dob as a combination to match. Amazingly unique and unchanging combination, that one! /s
michaelt 2y ago
Hash-based solutions aren't as easy as we might hope. You store a hashed version of my SSN, or my phone number, to represent my opt-out? Someone can just hash every number from 000-00-0000 to 999-99-9999 and figure out mine from that. You hash the entire contents of the profile - name+address+phone+e-mail+DOB+SSN - and the moment a data source provides them with a profile only containing name+address+email - the missing fields mean the hashes won't match. A trusted third party will work a lot better IMHO. And of course none of the data brokers have much reason to make opt-outs work well, in the absence of legislation and strict enforcement - it's in their commercial interests to say they "can't stop your data reappearing"
- makmanalp 2y ago
  > Someone can just hash every number from 000-00-0000 to 999-99-9999 and figure out mine from that. That's what salts are for, right? It wouldn't be too hard to issue a very large, known, public salt alongside each SSN. > And of course none of the data brokers have much reason to make opt-outs work well, in the absence of legislation and strict enforcement - it's in their commercial interests to say they "can't stop your data reappearing" This is the actual reason, IMHO.
  - ses1984 2y ago
    If the salt is public, what’s the point, then you can get all the salts, and combine them with every possible ssn, and you’re back where you were before.
    - makmanalp 2y ago
      No, that is kind of the point of a salt is that it doesn't need to be hidden - it's designed for a scenario where e.g. your database is hacked and they're visible as plaintext: https://en.wikipedia.org/wiki/Salt_(cryptography) https://en.wikipedia.org/wiki/Salt_(cryptography) Since the salts are random, unique to each SSN and long: a) you'll find no existing rainbow table that contains the correct plaintext for your SSN hash and b) each SSN now requires its own bruteforcing that is unhelpful for any of the other SSNs Combine that with a very expensive hashing method like PBKDF2 (I'm sure there's something better by now) and you've made it pretty dang hard for non state actors to bruteforce a significant chunk of SSNs. There's also peppers that involve storing some more global secrets on HSMs. I'm sure the crypto nerds have like a dozen better methods than what I can come up with but the point is this is not a feasibility issue.
      - deleted 2y ago
        [deleted]
      - ses1984 2y ago
        I’m sorry but it’s not that simple. You can’t just say add salt, here are the benefits of salt, problem solved. In a password database, salt is not secret because the password combined with it is secret and can be anything. Even if you know the salt for a particular user, in order to crack that user, you need to start hashing all possible passwords combined with that salt. If a user picks a dumb password like password123, then they are not safe if the salt leaks. Other users with password=password123 will not be immediately apparent because other users have different salts. You would have to try password123 combined with each user’s salt to identify all the users with password123. You said “It wouldn't be too hard to issue a very large, known, public salt alongside each SSN.” That means there should be some theoretical service where you pass it an ssn and get back the salt, right? So what have you gained? Any attacker with an ssn can get the salt, and nothing was gained. Or if attackers don’t have ssns they can just ask for all the salts, the mapping from ssn to salt is public so they know 000-00-000 has salt1, 000-00-001 has salt2, etc, so you haven’t increased the amount of hashes attackers have to do to do whatever it is they want to do. You’re right about commercial interests being at play. That’s why we don’t have laws like GDPR in the USA. Crypto nerds have thought about this long and hard and if it was that easy we wouldn’t need stupidly complex laws like GDPR. They would “just add salt.” Or other services would “just add salt” instead of relying on more complex and expensive forms of identity verification and protection. You don’t need to be a crypto nerd to try to describe a flow where having a public known salt per ssn helps with privacy. You do not need to be a crypto nerd to design secure one way hash functions that would plug into that flow.

by hedora 2y ago

lazide 2y ago

Yup, it would be trivial to create a one way hash of various attributes to perma ‘opt out’ someone. But how would they keep making money that way?

zo1 2y ago

So for a perfect match they'd need to have some sort of unique identifier that's present in the first set of data you ask them to remove, as well as being present in any subsequent "acquisitions" or "scrapes" of your data. If these devs that scrape/dump/collate all this info are anything like the ones I've seen, and they're functioning in countries like the US and UK whereby you don't have individual identifiers that are pretty unique, then I'd say the chance of them being able to get such a "unique" key on you to remove you perpetually, is next to impossible. And if it's even close to being "hard", they'll not even bother. Doubley-so if this service/people/data is anything like the credit-score companies, which are notoriously bad at data de duplication and sanitation. Likewise, if you want them to do some sort of removal using things other than a unique identifier, then you have to have some sort of function that determines closeness between the two records. From what I've heard, places like Interpol, countries' border-control and police agencies usually use name, surname and dob as a combination to match. Amazingly unique and unchanging combination, that one! /s

michaelt 2y ago

Hash-based solutions aren't as easy as we might hope. You store a hashed version of my SSN, or my phone number, to represent my opt-out? Someone can just hash every number from 000-00-0000 to 999-99-9999 and figure out mine from that. You hash the entire contents of the profile - name+address+phone+e-mail+DOB+SSN - and the moment a data source provides them with a profile only containing name+address+email - the missing fields mean the hashes won't match. A trusted third party will work a lot better IMHO. And of course none of the data brokers have much reason to make opt-outs work well, in the absence of legislation and strict enforcement - it's in their commercial interests to say they "can't stop your data reappearing"

makmanalp 2y ago
> Someone can just hash every number from 000-00-0000 to 999-99-9999 and figure out mine from that. That's what salts are for, right? It wouldn't be too hard to issue a very large, known, public salt alongside each SSN. > And of course none of the data brokers have much reason to make opt-outs work well, in the absence of legislation and strict enforcement - it's in their commercial interests to say they "can't stop your data reappearing" This is the actual reason, IMHO.
- ses1984 2y ago
  If the salt is public, what’s the point, then you can get all the salts, and combine them with every possible ssn, and you’re back where you were before.
  - makmanalp 2y ago
    No, that is kind of the point of a salt is that it doesn't need to be hidden - it's designed for a scenario where e.g. your database is hacked and they're visible as plaintext: https://en.wikipedia.org/wiki/Salt_(cryptography) https://en.wikipedia.org/wiki/Salt_(cryptography) Since the salts are random, unique to each SSN and long: a) you'll find no existing rainbow table that contains the correct plaintext for your SSN hash and b) each SSN now requires its own bruteforcing that is unhelpful for any of the other SSNs Combine that with a very expensive hashing method like PBKDF2 (I'm sure there's something better by now) and you've made it pretty dang hard for non state actors to bruteforce a significant chunk of SSNs. There's also peppers that involve storing some more global secrets on HSMs. I'm sure the crypto nerds have like a dozen better methods than what I can come up with but the point is this is not a feasibility issue.
    - deleted 2y ago
      [deleted]
    - ses1984 2y ago
      I’m sorry but it’s not that simple. You can’t just say add salt, here are the benefits of salt, problem solved. In a password database, salt is not secret because the password combined with it is secret and can be anything. Even if you know the salt for a particular user, in order to crack that user, you need to start hashing all possible passwords combined with that salt. If a user picks a dumb password like password123, then they are not safe if the salt leaks. Other users with password=password123 will not be immediately apparent because other users have different salts. You would have to try password123 combined with each user’s salt to identify all the users with password123. You said “It wouldn't be too hard to issue a very large, known, public salt alongside each SSN.” That means there should be some theoretical service where you pass it an ssn and get back the salt, right? So what have you gained? Any attacker with an ssn can get the salt, and nothing was gained. Or if attackers don’t have ssns they can just ask for all the salts, the mapping from ssn to salt is public so they know 000-00-000 has salt1, 000-00-001 has salt2, etc, so you haven’t increased the amount of hashes attackers have to do to do whatever it is they want to do. You’re right about commercial interests being at play. That’s why we don’t have laws like GDPR in the USA. Crypto nerds have thought about this long and hard and if it was that easy we wouldn’t need stupidly complex laws like GDPR. They would “just add salt.” Or other services would “just add salt” instead of relying on more complex and expensive forms of identity verification and protection. You don’t need to be a crypto nerd to try to describe a flow where having a public known salt per ssn helps with privacy. You do not need to be a crypto nerd to design secure one way hash functions that would plug into that flow.