Hacker News Reader

Comment by kenniskrag | Hacker News Reader

"log a non-reversible hash of the IP address to improve the accuracy of the daily statistics."

2**32 IP addresses seems not to be hard to reverse. Am I wrong?

It might become a bit harder if they salt the hash with some other data, but no. Especially because you can reduce the search set even more.

Even though in the specific case of audacity, I'm not sure what the negative implications of a disclosure "I use audacity" by access-log of a server would be. So to me it's fine.

The whole telemetry would be correlated to the IP. I'm not sure what they gather now.

For sure, unless they use a very computationally expensive hash.

Beyond that I'm not sure why they'd get from that, given that non-static IP addresses are very common on the internet and NATed networks even more so.

IP are considered PII and are regulated. So the easiest way is to avoid PII.

If you XOR the four octets into a single byte then it’s definitely irreversible :^) (and also pretty useless for telemetry purposes)

they could also just generate an "installation" id ? this also works more accurately when the computer switches ip addresses.

> works more accurately

That's what they want to avoid. An advantage is, that you can ask the user for the id an check the logs for debugging.

You could generate an 128-bit installation ID and then send [date, hash(id, date)]. Now when you're debugging with a user you can ask for their ID and see which traffic is theirs.

won't work because date = receive date and now you have a unique id and an IP.

Sorry, why won't it work? The idea is that as long as you don't know the ID you can't tell which traffic is coming from the same person across whatever time duration you choose to bucket at (finer bucketing gives more privacy but also more computation to decode the logs once given the ID).

And if I give you x and hash(x, y), this does not tell you what y is (it just lets you very likely confirm y if you have it)

Reply on news.ycombinator.com