4 ms·

Maybe I'm missing something but (1) I don't think this is GDPR compliant, and (2) why so complicated? Regarding (1), > Brute forcing a 256 bit hash would cost

by tomp 7y ago

Maybe I'm missing something but (1) I don't think this is GDPR compliant, and (2) why so complicated? Regarding (1), > Brute forcing a 256 bit hash would cost 10^44 times the Gross World Product (GWP). [...] > We have rendered the data anonymous to the point where we could not identify a natural person from the hash. > It's possible that GDPR does not apply to Fathom since data is made completely anonymous. Even if GDPR did still apply, we reiterate the stance that there is legitimate business interest to understand how your website is performing. This seems to imply a profound confusion between the difference of hashing vs. anonymity. Just because it's hashed doesn't mean it's anonymous! You don't need to "brute-force" the hash, you just need to find a user that matches your hash... which is 1 in 7 billion (or so), much more tractable. This is also the principle e.g. MD5 rainbow tables are based on... They claim to change the hash every 24 hours, so it's equivalent to having a session cookie with 24-hour expiration (session cookies are "anonymous" by their definition, they don't have any user information and they're impossible to "brute force", they "just" enable tracking). I've no idea if 24-hour session cookies are GDPR-compliant... Regarding (2), given that this seems (again, I might be misunderstanding) equivalent to a 24-hour session cookie, why not just do that? However, then you're ... drumroll ... giving control to the user. Why not just give control to the user, period?! For example, by storing the list of pages visited in Local Storage, and only pinging the server once for each page(view) every 24 hours?

JackWritesCode 7y ago
For GDPR compliance notes please see: https://usefathom.com/data/ https://usefathom.com/data/ > You don't need to "brute-force" the hash, you just need to find a user that matches your hash... which is 1 in 7 billion (or so), much more tractable. This is also the principle e.g. MD5 rainbow tables are based on... Not quite. We use a SHA256 hash as our salt, and that changes each day, so you'd need to brute force that. In terms of how many possible combinations there are for this salt, please see: https://stackoverflow.com/a/49520766 https://stackoverflow.com/a/49520766 - you would need to brute force it and try each possible combination with every single possible IP / User Agent / Site combination to break a hash. This is why it's not theoretically impossible but it's practically impossible. We would love to approach things in an easier way but PECR doesn't want cookies, even anonymous ones. Now, one thing that we have uncovered thanks to someone on here is that we need to increase our resistance to data breaches. If someone had complete, unlimited access to all our data / servers, including the daily salt, then they could de-hash page views from the last 30 minutes. I have no idea how long that would take. There are 4,294,967,296 (?) possible IP addresss, and then over 3M (?) user agents, so it'd be an absurd, pointless exercise.... Anyway, we're going to be bringing in multiple salts that depend on the user IP address, meaning that, in the event of a data breach, a hacker won't know which salt has been used for a hash :) Perhaps we base the salts on the first 3 digits of an IP address? That would mean we'd have 720 possible SHA256 salts!
- hedora 7y ago
  You can get an order of magnitude on hash collision resistance by rolling every two hours. Maintain “two” backend databases to gracefully track sessions between roll overs. Also, for non GPDR IP blocks, maybe just store a per client salt in a cookie(!) and then xor it with the rotating server salt.
  - JackWritesCode 7y ago
    I’m not worried about hash collision with sha256. Any reason why I should be? :) And we can’t use cookies because of PECR!

by tomp 7y ago

JackWritesCode 7y ago

For GDPR compliance notes please see: https://usefathom.com/data/ https://usefathom.com/data/ > You don't need to "brute-force" the hash, you just need to find a user that matches your hash... which is 1 in 7 billion (or so), much more tractable. This is also the principle e.g. MD5 rainbow tables are based on... Not quite. We use a SHA256 hash as our salt, and that changes each day, so you'd need to brute force that. In terms of how many possible combinations there are for this salt, please see: https://stackoverflow.com/a/49520766 https://stackoverflow.com/a/49520766 - you would need to brute force it and try each possible combination with every single possible IP / User Agent / Site combination to break a hash. This is why it's not theoretically impossible but it's practically impossible. We would love to approach things in an easier way but PECR doesn't want cookies, even anonymous ones. Now, one thing that we have uncovered thanks to someone on here is that we need to increase our resistance to data breaches. If someone had complete, unlimited access to all our data / servers, including the daily salt, then they could de-hash page views from the last 30 minutes. I have no idea how long that would take. There are 4,294,967,296 (?) possible IP addresss, and then over 3M (?) user agents, so it'd be an absurd, pointless exercise.... Anyway, we're going to be bringing in multiple salts that depend on the user IP address, meaning that, in the event of a data breach, a hacker won't know which salt has been used for a hash :) Perhaps we base the salts on the first 3 digits of an IP address? That would mean we'd have 720 possible SHA256 salts!

hedora 7y ago
You can get an order of magnitude on hash collision resistance by rolling every two hours. Maintain “two” backend databases to gracefully track sessions between roll overs. Also, for non GPDR IP blocks, maybe just store a per client salt in a cookie(!) and then xor it with the rotating server salt.
- JackWritesCode 7y ago
  I’m not worried about hash collision with sha256. Any reason why I should be? :) And we can’t use cookies because of PECR!