Apologies for the rather opaque title of this post. In its expanded form, it would read something like this: “IP addresses: are they personally identifiable information within the meaning of the law, or not?”… but that would be a bit long.
The question is prompted by the latest legal ruling on the subject, this time from a US federal judge in Seattle, issuing a written decision in a class-action case between consumers and Microsoft. The judge ruled that they are not: IP addresses identify computers, not people, he concluded, and therefore do not constitute personally identifiable information.
I think there’s a technical and a pragmatic side to any discussion of this conclusion. Technically, the argument could well rumble on; after all, if I tell you the IP address “”, does that identify anything, let alone a person versus a computer? It is probably recognisable as the default starting point for the IP address range behind the average domestic firewall/router. So, the address “” doesn’t uniquely identify any computer… but then again, the address the firewall/router exposes to the ISP doesn’t uniquely identify any of the computers it shields, either… so on examination, the judge’s argument doesn’t stand up – as presented, at least.
Does the pragmatic approach fare any better? Well, in some jurisdictions the argument has already moved on. In some EU member states, the current position is closer to this: IP addresses constitute personally identifiable information if the entity processing them can reasonably be considered to have access to data, linkable to the IP address, which would identify an individual. That makes a certain amount of sense, in that ISPs, for instance, need to establish enough of a link between an IP address and an individual to send them a bill. On the other hand, it doesn’t prove that the person responsible for paying the bill has anything to do with the internet traffic terminating at that IP address (for instance, I might pay for my child’s broadband subscription while they are at college). As a little experiment, try visiting Dave Birch’s blog, here. While you’re there, incidentally – check out the content; it’s excellent. Then have a look in the right-hand margin, and see how close Feedjit gets to personally identifying you. In my case, it gets as far as the neighbouring town – about 5 miles away – and therefore lumps me in with a population of over 60,000 people.
In the sense of “IP addresses being sufficient to uniquely identify an individual”, then, the pragmatic approach doesn’t look too healthy either. However, where I think it scores is in its ability, potentially, to make the decision conditional on other factors – such as, in this case, how much other data the IP address can be linked to by any given party who sees it. After all, it’s reasonable to assume that the ISP, in this case, can more easily work out who a given IP address is assigned to than could the man on the proverbial No.38 bus (Victoria to Clapton, via Piccadilly and Angel, incidentally).
In other words, if you are the data controller for both the IP address and the billing data, you would do well to behave as though the IP address was PII. That seems reasonable enough. In some cases, it may mean being able to prove that you have taken steps to prevent one from being linked with the other. That seems reasonable enough, too.
Looking a little further down the line, though, the pragmatic approach will run into some interesting obstacles. The same logic, after all, will mean that in some circumstances the words “Yes” and “No” will need to be treated as personally identifiable information. For example, suppose you are in a position to link the following pieces of data:

  • Individual (subscriber, patient, etc)
  • Question (Is this individual over 18?)
  • Answer (Yes/No).

Good practice (read Dave Birch’s piece on Psychic ID for a great example) is to reduce disclosures of personal attributes to Yes/No answers to closed questions… and that’s both a laudable ambition and a good design objective. It won’t solve the “what is PII?” riddle, though.