3 ms·

"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?

simias 5y ago
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.
- kenniskrag 5y ago
  IP are considered PII and are regulated. So the easiest way is to avoid PII.
layoutIfNeeded 5y ago
If you XOR the four octets into a single byte then it’s definitely irreversible :^) (and also pretty useless for telemetry purposes)
je42 5y ago
they could also just generate an "installation" id ? this also works more accurately when the computer switches ip addresses.
- kenniskrag 5y ago
  > 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.
- jefftk 5y ago
  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.
  - kenniskrag 5y ago
    won't work because date = receive date and now you have a unique id and an IP.
    - jefftk 5y ago
      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)
tetha 5y ago
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.
- kenniskrag 5y ago
  The whole telemetry would be correlated to the IP. I'm not sure what they gather now.

simias 5y ago

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.

kenniskrag 5y ago
IP are considered PII and are regulated. So the easiest way is to avoid PII.

layoutIfNeeded 5y ago

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

je42 5y ago

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

kenniskrag 5y ago
> 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.
jefftk 5y ago
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.
- kenniskrag 5y ago
  won't work because date = receive date and now you have a unique id and an IP.
  - jefftk 5y ago
    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)

tetha 5y ago

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.

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