Operators should be free to log traffic at the network level, PII should only come into play once you're asking someone to provide personal information.
Operators should be free to log traffic at the network level, PII should only come into play once you're asking someone to provide personal information.
Household IP Targeting - https://www.vicimediainc.com/ip-targeting-direct-mail-intern...
Or even just your ISP (who for sure know your IP addr and your address) - https://arstechnica.com/information-technology/2017/03/how-i...
The larger issue that we (HN tech people) treat IPs as fallible because we're thinking of it like an absolute. The advertising side of the Internet looks at them like a goldmine b/c even a 75% correlation to "truth" can still make their ads reach the people they're trying to reach in a much cheaper way.
I wouldn't be surprised if some policies pertaining to record keeping in some sectors contradict that requirement as well.
https://termsfeed.com/blog/gdpr-recitals/#Recital_49_8211_En...
Amusingly enough, California consumers will not have privacy rights regarding any written comments sent to the California Attorney General.
The IP is a an identifier, so unlike password salt (where the user is the identifier) you need a way to know what the salt is to hash the IP, and it needs to be consistent.
You can do a lookup table of IP-to-salt, but this either gives away your list of addresses (if only containing IPs you've seen) or is huge (entire ipv4 range), and either way doesn't prevent rainbow tables.
You can have a static salt for the entire site, but again this is not really helping much against rainbow tables (beyond requiring recalculating the table, once).
Is there a mitigation I'm not thinking of?
If you need the ability to group ciphertexts without decrypting them, you could create a scheme which will make cryptographers cringe, but could be justified in this specific case.
For instance, you can probably assert things like which IP blocks are likely to comprise most of the entries in the table or which IP blocks or addresses cannot be in the table.
That just makes me all sorts of uncomfortable.
Modern GPUs can manage several thousand million SHA256 hashes/sec, so even with a salt per hash it’s not going to take long to get a given entry, given the 32bit address space of IPv4
If I am got a DoS attack or Spam, I need the IP to find out to whom I should file abuse complain.
Do we need to sanitize SMTP header too? How about shuting down DNSBL?
From security point of view, if you use a fixed (unrelated to input) salt, the attacker will have a harder time to discover the function f (unless you store the salt next to your IP hashes). But from privacy point of view, in relationship between me (user) and you (service provider), you are the attacker. And you know your function f. Hashing IPv4 addresses, salt or not, gives me no privacy protection, since you can trivially reverse the hash - just due to small domain size. With IPv6, this problem will resolve itself somewhat; till then, I'd prefer if you encrypted those IPs with keys that have finite and short life time, in a way that a third party could audit if need be.
Simply out of curiosity, what do you mean by that?
All my life experience and knowledge tells me it's exactly how you get around the law, unless court has its own agenda or strong bias.
However I'm not sure myself it makes sense. Some people will be identified by just a partial IP or even a partial hash.
Combine that with cross-site tracking and phone companies selling your info...
If IP addresses were as anonymous as claimed, there would be little incentive to save them in any long time storage.
Until I hear otherwise, I'm going to gamble that for now that's not the kind of reckless mishandling of personal information that regulators are trying to crack down on.
And you're probably right until they do otherwise.
The problem with badly-drafted laws is that they can be used to attack people who are annoying but who haven't done anything wrong... except for technically violating a law which is "supposed to" mean something else but which can be read to penalize some harmless activity the gadfly happened to engage in.
So, maybe you'll be patient when I'm not comforted by people telling me to not worry about it.
But we also have to have a certain pragmatism when deciding how to behave in a society with an impossible legal system. How much effort should I, as a developer or as a consultant to business owners or as a systems administrator, spend on purging IP addresses versus all the other things that need attention?
For that we look to how the law is applied in practice.
I was active on Slashdot back when the DMCA was first proposed and then fought its way into becoming law. There is no topic about which HN is as rancorous as Slashdot was about the DMCA. What does the situation look like now, twenty years later? Yes, there are and have been and continue to be abuses of the DMCA, but not at the internet-destroying scale that Slashdot predicted.
So I'm not going to tell you to ignore IP addresses in your log files. That's up to your judgement. But I'm going to ignore them in mine, until I see a reason to do otherwise, and when it's a topic of discussion with others, I'll tell them that according to a strict reading of the law, logged IP addresses may be a liability, but that there have been exactly 0 cases to date which have been only about some business having IP addresses in its logs for abuse and diagnostic purposes.
There's lots of talk about consent as a basis for processing. For lots of purposes "Legitimate Interests" is likely a better basis. You'll have to perform a legitimate interests assessment and be able to justify that the potential negative impact of your processing is outweighed by the benefits.
The ICO has a interactive tool for selecting a basis for processing https://ico.org.uk/for-organisations/resources-and-support/l... with links to more information.