English
Deutsch
PolskiWhat Truncating an IP Address Actually Anonymises
Contents
Dropping the last octet is the standard answer to the IP question, and it is a reasonable one. What almost never follows is the second step: saying how large the group is that a visitor now disappears into. The measure is treated as a switch – masked or not masked – when it is a dial, and where the dial sits decides whether anything was achieved.
The numbers are small enough to do in one’s head, and they are worth having ready the next time someone asks whether the data is anonymous now. It usually is not, and that is not an argument against truncation – only against the sentence that follows it.
How Large the Remaining Group Really Is
Truncation works in bits: each bit dropped doubles the number of addresses that share the stored value. Dropping a whole octet leaves 256 addresses with that value. To interpret that number, we also need to consider what a single address represents.
| Stored | Addresses sharing it | What it still says |
|---|---|---|
203.0.113.45 |
1 | One connection – in a household, one household; in a company, one office. |
203.0.113.0 (/24) |
256 | Usually one provider block in one city, often one street or one building. |
203.0.0.0 (/16) |
65 536 | A region and a provider, no longer a place. |
| nothing | all of them | Nothing – and that is the only value that removes the reference. |
The middle row is where the argument usually happens. 256 addresses are not 256 people: a residential block from a provider is handed out to a few dozen connections at a time, and behind a corporate NAT the whole building leaves through one address. In one direction the group is smaller than the number suggests, in the other much larger – and neither is visible in the data itself.
That is why truncation is best described as what it is: a reduction of precision, sized in bits, that lowers risk without ending the personal reference. A /24, a timestamp to the second and a user agent are together narrow enough that supervisory authorities have treated the combination as personal data, and no amount of masking on the last octet changes that.
Why a Hash Is Not an Alternative
The suggestion arrives in every second discussion: store the hash instead of the address, then the value is unreadable. It is unreadable, and it is not anonymous – because the space it was drawn from is tiny.
IPv4 has about 4.3 billion addresses. A single ordinary machine computes SHA-256 in the order of hundreds of millions of hashes per second, so the complete table of every address and its hash is built in minutes and fits on a laptop. A hashed IPv4 address is therefore not a pseudonym; it is the address written in a different alphabet, and the lookup that undoes it is a rounding error in effort.
A per-event salt breaks the table, but it also breaks the only reason the value was kept: two events from the same visitor no longer match. A fixed salt keeps the joins and merely turns the table into a slightly more expensive one, computed once and reused for every record in the same dataset. What remains genuinely useful is a hash over the truncated address, where the group of 256 is what gets hashed – the protection comes from the truncation, not from the hash.
IPv6 Truncates Differently Than It Looks
The rule that was carried over from IPv4 – drop the last quarter – does almost nothing in IPv6, because the address is structured differently. A connection is usually handed a whole /64, and every device behind it invents its own suffix inside that block. Cutting an address down to its /64 therefore removes the device but keeps the connection, which is exactly the identifier that mattered.
Meaningful truncation starts one step further left. A /56 or /48 is what a provider assigns to a site, so that is where a group larger than one household begins. Google’s own rule for IPv6 – zeroing the last 80 bits, which leaves a /48 – sits at that point rather than at the visually equivalent quarter.
One case survives all of this unnoticed: an IPv4 address wrapped in IPv6 notation, written as ::ffff:203.0.113.45. Masking rules that count from the right leave the embedded address intact far longer than expected, and a value that looks like a masked IPv6 address can carry a complete IPv4 one.
Where in the Flow the Truncation Sits
Masking is only masking if it happens before the address leaves the perimeter, and that distinction separates two cases that are otherwise described in the same words.
In a server-side setup – a conversions API, a container on one’s own infrastructure – the address is a field in a payload. Whatever is written into client_ip_address is what the recipient learns, so truncating before the request is sent removes the last octet for good. This is the case where the measure does what it claims.
With a tag that runs in the browser, the situation is the reverse. The request goes to the vendor directly, and the address the vendor sees is the one on the connection, not the one in the payload. A masked value in a parameter changes what is stored in a report; it does not change what arrived at the edge. Only a proxy through one’s own domain moves that boundary, and then the address the vendor sees is the server’s.
What Truncation Is Actually For
The purpose is easier to defend once it is stated precisely. A /24 still resolves to a city and often to a district, which is the entire point: the geographic reporting that the address was collected for survives the cut almost unchanged, while the value that identifies a single connection is gone. The measure is well chosen for that trade, and poorly chosen for the claim that the data is now anonymous.
Documentation follows from the same sentence. A record of processing that states the mask length, the point in the flow where it is applied and the resulting group size describes something checkable. One that states “IP addresses are anonymised” describes a switch that does not exist, and the first question from anyone reviewing it will be the one this article started with: how large is the group.
Questions and answers
How large is the group behind an IPv6 value truncated to /48?
That depends on what the provider assigns to a connection. A /48 contains 256 blocks of size /56 and 65,536 blocks of size /64. If households receive a /56 each, up to 256 connections share the truncated value; the number equals the one for an IPv4 /24, except that here it counts connections rather than addresses. If they receive a /64 each, correspondingly more.
If a site receives a whole /48 itself, as happens with companies, truncation removes nothing that identifies it: the stored value still stands for exactly that one connection. The group size a record of processing should state is therefore not a fixed number in IPv6 but depends on the providers’ allocation practice, and for a site with its own /48 it is one.
Does a secret key help, such as an HMAC instead of a salt?
It helps against outsiders, not against the personal reference. As long as the key stays secret, the table of addresses and values cannot be computed without it, and a leaked dataset is worth considerably less to third parties. Whoever holds the key, however, computes the table in minutes just as with an unsalted hash, because the address space stays the same.
Since the controller keeps the key itself, the values are pseudonyms to it, not anonymous data. An HMAC over the full address is therefore a good safeguard, but it replaces neither the truncation nor the statement in the record of processing that personal data is held here.
Where does the full address still appear although the analytics tool truncates it?
Wherever the connection arrives before the truncation takes effect. The usual places:
- the web server’s access log, which in the default configuration of Apache and nginx writes the complete address of every request,
- the error log, which records the client’s address with many errors,
- a CDN, a web application firewall or a load balancer in front of the server, each with its own logs, plus the X-Forwarded-For header that passes the original address on to the server,
- blocking tools such as fail2ban, which store addresses in full precisely because they are meant to block them,
- backups that include all of the above, possibly with longer retention than the original.
None of these places is wrong in itself, and some are necessary for operation. They do belong in the record of processing with purpose and retention period, though; otherwise the record, by describing the masking in the analytics tool, covers only the smallest part of the processing.
How do IPv4 addresses in IPv6 notation end up in the data at all?
Frequently through a server that also accepts IPv4 connections on an IPv6 socket. The operating system then reports them as ::ffff:203.0.113.45, and that is exactly how they land in logs and applications. A masking rule should therefore first check whether the value begins with ::ffff: and then truncate the embedded IPv4 address according to the IPv4 rule.
Sources
Related articles
