Why the exclusion list is not hashed

If you build a site, you open it twenty times a day. On a counter with forty visitors a month, half the statistics are you. So there is a setting: do not count visits from my own address.

Everywhere else in this service, addresses are hashed with a secret salt and a date, and the address itself never reaches storage. In this one place it is stored as you typed it, in the clear. That is a deliberate decision and it deserves saying out loud rather than being left to be discovered.

The version that was tried first

The first implementation stored a checksum of the address, consistent with everything else. It worked, it stored less, and it was close to useless: most home connections get a new address every day. The exclusion was correct when you set it and worthless the following morning.

What survives a daily change is a range — typically the provider's /24 or /16, which stays the same while the last part rotates. And a range cannot be compared as a checksum. Hashing destroys order on purpose, and "is this address inside this range" is a question about order. There is no clever way around it; the two requirements point in opposite directions.

So the range is stored as entered, normalised, alongside its two boundaries as sixteen bytes each, and a single BETWEEN decides. IPv4 is written in its IPv6 form so both families are the same width and one comparison covers both.

Why this trade is acceptable here

What is stored is the operator's own network, typed in by them, displayed back to them, and deletable by them at any moment. It is not a visitor's address. The privacy policy says the same thing in the same words, because the alternative — describing the service as hashing everything and quietly excepting this — would be the kind of true-in-outline claim that is worth less than no claim.

The limit is ten entries per counter: enough for home, office and mobile, few enough that the list cannot become a general-purpose store of addresses.

The second kind, for things that move

Some traffic has a stable identity and an unstable address: your own uptime monitor, a link-preview fetcher from a chat program, a checking service. No range catches those.

For them the exclusion matches a fragment of the browser identification instead. Entering uptimerobot catches the full string it sends. The minimum is four characters, because a two-letter fragment would appear in nearly every identification string and switch off the counter entirely.

The general point

A privacy design is a set of trades, and the interesting parts are where a rule had to bend. Rules that never bend usually mean nobody has tested them against a real requirement yet.

The thing to avoid is bending one quietly. A hashed field that is not really hashed, described in the documentation as though it were, is worse than a plain field described plainly — it spends trust it has not earned, and it will be found eventually by someone who did not expect to have to check.