Not private enough as the space of IP addresses is too small. Removing the last octet of IPv4 addresses before storing them should provide better privacy.

> Removing the last octet of IPv4 addresses before storing them should provide better privacy.

That doesn't provide any practical amount of privacy. For a longer discussion of why this is at best a placebo, see: https://news.ycombinator.com/item?id=17170468

I solved this my SaaS by internally logging all the requests and then using the Measurement Protocol (https://developers.google.com/analytics/devguides/collection...) to send them from the server-side. While doing that I also set the last digit to 0 and unify user agents and other data that's not important for me.

A plain hash doesn't make a difference.

One can use hashes with regularly changing salts that are destroyed after a while to make older hashes unusable though for some purposes.

When you can trivially crawl the input space like ipv4 addresses, you'd have to expire a fresh per-day salt as well.

But to my eyes, expiring salts isn't much different than deleting ip addresses after one day. Just more machinery. People have to trust that you're doing either, so why bother beyond being able to use the word "hashing" in marketing language?

You'd at least want per record salts. But even then it's trivial to check if a given ip is in the dataset. Better, but not great. (ie: you have access to the dataset, you want to check if a given ip/time match the log - read the salt, check the hash).

But per record hashes break the original use case: checking if a given hash is already in the database.