6 ms·

Court confirms that IP addresses are personal data only in some cases (2016)

64 points by ptype 8y ago

Eridrus 8y ago
This is an odd ruling to me. If an ISP is willing to sell that data, are IP addresses now PII for everyone? If one part of a company has such a DB, does it apply to every part of the company? What if it's multiple companies owned by a conglomerate? If you include an image (or a font!) from somewhere else in a web page, you are causing the user's IP address to be sent to the hosting party, are you liable for sending PII if the target can link IPs to names, because they (e.g. Google) have a DB?
- geofft 8y ago
  > If you include an image (or a font!) from somewhere else in a web page, you are causing the user's IP address to be sent to the hosting party, are you liable for sending PII if the target can link IPs to names, because they (e.g. Google) have a DB? As an end user, I want this—if you wouldn't send my IP address to these people otherwise, wanting to show me an image or a font is not a good reason to send it. As a web developer, I am happy to have excuses to tell my teammates that we need to rehost every asset we depend upon. It's the right thing to do for so many other reasons. I know this makes things hard for people who have webfonts that don't allow rehosting them etc. Being able to say "We can't use this font because of GDPR unless you change your policies" sounds pretty great honestly.
  - StudentStuff 8y ago
    Hosting every dependency should be the norm, that some sites pull in multiple megs of dependencies from random third parties is just asking for trouble long term. On the topic of proprietary fonts, why do some websites seem to think using a questionably legible, licensed font is a good idea? It isn't adding value for the end user.
- shabble 8y ago
  What's the intended harm that restricting people from linking to uncontrolled 3rd party assets would prevent/mitigate? Consider: You're CompanyX, and I'm DodgyFontHost.tld My business model is exploiting and selling as much data as I can gather/mine from my traffic. You embed (that is, reference/hotlink) some of my fonts on your pages. If a user visits your page, and as a result makes a request to me for a font, I can log everything about that request, but I don't (afaik) have much/any additional knowledge that makes it particularly useful. Assume there's no ?UTM=... tracking content in the url itself, you're just referencing a static font file. I'm not sure offhand if browsers would be passing a referer header by default, or if that could somehow reliably identify the site I'm actually visiting. If so, that'd be one valuable fact. I might be able to fingerprint the users browser from other headers or their OS from network-level quirks. Anything else I'm missing? I feel like 'IP $x made a request for $file' isn't the important thing to be looking at here, it's what I can learn from other things associated with the request that I can exploit. But yes, if you had a reliable lookup from (ip,timestamp) to legal person, then it's absolutely Personally Identifiable. Imagine if every browser set a valid, correct 'X-Requestors-Legal-Name: Bob Smith, Sometown, USA' header on every request. That's obviously identifiable. Adding a layer of indirection doesn't make it less so, although it does maybe place it on a continuum of 'cost/effort to identify based on this info'. It ranges from 'trivial, because it's right there in the content you're sending', through 'not directly, but easily enough via subscriptions to one or more commercial data providers' to 'if someone steals our data and combines it with stolen data from several other sources, they have a non-zero chance of guessing your identity correctly'.
  - clarry 8y ago
    > I'm not sure offhand if browsers would be passing a referer header by default, or if that could somehow reliably identify the site I'm actually visiting. If so, that'd be one valuable fact. They are passing referer unless the context is an encrypted connection and the resource is on plain HTTP. Firefox also strips out the path from the URL for third party requests, but only in private browsing mode: https://blog.mozilla.org/security/2018/01/31/preventing-data-leaks-by-stripping-path-information-in-http-referrers/ https://blog.mozilla.org/security/2018/01/31/preventing-data... I think this should be the default for all third party domains no matter what the mode. (Really, I'd rather see that header just go away.)
- kekumu 8y ago
  If you use a third-party, they would be acting as your data processor. You'd need to make sure you have a contract with them that ensures they're respecting GDPR as well. I agree with others that you should self-host whenever possible. It will simplify these questions and you'll be able to fully protect your users' data yourself.
ptype 8y ago
I have submitted this because it is frequent to see on HN claims that IP addresses are personal data under GDPR. I’m yet to see a good source for this blanket statement, and this link contains a more nuanced analysis, essentially saying that IP addresses are only personal data in some cases, where they can be used to identify a person (without involvement of the ISP).
- lurker456 8y ago
  GDPR is more recent and supersedes this.
  - tjoff 8y ago
    Though the exact same reasoning applies.
  - killjoywashere 8y ago
    I'm fairly certain the US legal system, when interpreting domestic cases (the purview of HIPAA) doesn't care about the GDPR. If a case crossed international boundaries, sure, but to say GDPR supersedes HIPAA is false. They apply to different jurisdictions, which are mostly, if not entirely, separate.
    - lurker456 8y ago
      Agreed, the US is more lax. I was responding to the parent comment "I have submitted this because it is frequent to see on HN claims that IP addresses are personal data under GDPR"
- killjoywashere 8y ago
  IP addresses are also considered PHI under HIPAA. This is new to the GDPR.
  - zaroth 8y ago
    IP addresses are not themselves PHI, but the presence of IP addresses is considered to make PHI “individually identifiable”. IP addresses must be removed when you are de-identifing PHI. You also, by the way, must remove any geographic information more specific than a state, such as ZIP codes. So it doesn’t say much to include IP addresses in the deidentification list.
deleted 8y ago
[deleted]
jlgaddis 8y ago
The main takeaway (IMO) from this article is right here: > However, businesses should note that if they have sufficient information to link an IP address to a particular individual (e.g., through login details, cookies, or any other information or technology) then that IP address is personal data, and is subject to the full protections of EU data protection law.
- clarry 8y ago
  Can we interpret have as can obtain? Do a geolookup, you have my approximate location. Do a Google search for my IP address and you'll have my name.
  - jlgaddis 8y ago
    > Can we interpret have as can obtain? From my reading, you can interpret it that way if "the website operator has a 'legal means' of obtaining access to the information". Refer to the "What makes a dynamic IP address personal data?" section of TFA. (N.B.: I am not a lawyer. Ask your doctor if taking legal advice from strangers on the Internet is right for you.)
  - kekumu 8y ago
    I would. Better to be overly cautious if you're serious about protecting user data and privacy. IPs specifically are quite likely to reveal some identifying info, and it's obvious how trivial it is to find that info. Even the company itself isn't looking that info up, losing that info could expose their users.
  - threeseed 8y ago
    > Do a Google search for my IP address and you'll have my name. How does that happen exactly ?
    - dylz 8y ago
      Business class internet at home often will reassign it to your full name and address, for example.
deleted 8y ago
[deleted]
Lazare 8y ago
The coverage of GDPR I've seen (and in my view, the regulation itself) has been pretty clear that data becomes covered "personal data" only to the extent that the data, in aggregate, can be used to identify a real person. So an IP address on its own is almost never personal data, because of wifi, NAT, dynamic IPs, shared devices, etc. Then again, a name is almost never personal data on its own either, "John Smith" could refer to any one hundreds of thousands or people or it could be a pseudonym and refer to literally billions of people. But if someone registers on your site, and you log the IP address and their name, you're a lot closer to persona data. Add a timestamp, and you probably can identify a real person. So if you're trying to be careful about GDPR, you should probably be careful about storing IP addresses (or IP addresses that can be linked to other bits of potentially personal data). The focus of GDPR compliance can't be on "oh this field is fine, but this field is personal data", it should be on what you're collecting in aggregate. That makes IP addresses dangerous, because they provide a lot of information that could be used to identify someone.
- apple4ever 8y ago
  But as the article points out, adding a time stamp only will matter if you have access to other data to map it to a real person. So based on my reading, IPs and time stamps are not PII unless you are an ISP or you link them to other PII (so still the IP and time stamps are really irrelevant because they depend on that other PII).
  - shabble 8y ago
    You're unlikely to be storing only (IP, timestamp) data though. Presumably there's some additional info attached to those records that makes it useful for something. A web access-log records (ts, ip, request, ...), or maybe your application log stores (ts, ip, action, params, ...) So the information from that single source is "at time T, IP accessed RESOURCE". It's possible that's personally identifiable in context (if you have additional controls that RESOURCE can only be accessed by exactly 1 real person, etc) But say it's not. All you know is: Opaque PERSON accessed RESOURCE. if you can obtain the identifying information from elsewhere (buy, steal, etc) from ISP or whatever, you now know that (T, IP) = NAMEDPERSON. A simple lookup/matching means you know that NAMEDPERSON accessed RESOURCE. That's the new personal data. The IP isn't irrelevant, because without it, you'd have no lookup key to determine the mapping from PERSON? to NAMEDPERSON.

64 points by ptype 8y ago

This is an odd ruling to me. If an ISP is willing to sell that data, are IP addresses now PII for everyone? If one part of a company has such a DB, does it apply to every part of the company? What if it's multiple companies owned by a conglomerate? If you include an image (or a font!) from somewhere else in a web page, you are causing the user's IP address to be sent to the hosting party, are you liable for sending PII if the target can link IPs to names, because they (e.g. Google) have a DB?

geofft 8y ago
> If you include an image (or a font!) from somewhere else in a web page, you are causing the user's IP address to be sent to the hosting party, are you liable for sending PII if the target can link IPs to names, because they (e.g. Google) have a DB? As an end user, I want this—if you wouldn't send my IP address to these people otherwise, wanting to show me an image or a font is not a good reason to send it. As a web developer, I am happy to have excuses to tell my teammates that we need to rehost every asset we depend upon. It's the right thing to do for so many other reasons. I know this makes things hard for people who have webfonts that don't allow rehosting them etc. Being able to say "We can't use this font because of GDPR unless you change your policies" sounds pretty great honestly.
- StudentStuff 8y ago
  Hosting every dependency should be the norm, that some sites pull in multiple megs of dependencies from random third parties is just asking for trouble long term. On the topic of proprietary fonts, why do some websites seem to think using a questionably legible, licensed font is a good idea? It isn't adding value for the end user.
shabble 8y ago
What's the intended harm that restricting people from linking to uncontrolled 3rd party assets would prevent/mitigate? Consider: You're CompanyX, and I'm DodgyFontHost.tld My business model is exploiting and selling as much data as I can gather/mine from my traffic. You embed (that is, reference/hotlink) some of my fonts on your pages. If a user visits your page, and as a result makes a request to me for a font, I can log everything about that request, but I don't (afaik) have much/any additional knowledge that makes it particularly useful. Assume there's no ?UTM=... tracking content in the url itself, you're just referencing a static font file. I'm not sure offhand if browsers would be passing a referer header by default, or if that could somehow reliably identify the site I'm actually visiting. If so, that'd be one valuable fact. I might be able to fingerprint the users browser from other headers or their OS from network-level quirks. Anything else I'm missing? I feel like 'IP $x made a request for $file' isn't the important thing to be looking at here, it's what I can learn from other things associated with the request that I can exploit. But yes, if you had a reliable lookup from (ip,timestamp) to legal person, then it's absolutely Personally Identifiable. Imagine if every browser set a valid, correct 'X-Requestors-Legal-Name: Bob Smith, Sometown, USA' header on every request. That's obviously identifiable. Adding a layer of indirection doesn't make it less so, although it does maybe place it on a continuum of 'cost/effort to identify based on this info'. It ranges from 'trivial, because it's right there in the content you're sending', through 'not directly, but easily enough via subscriptions to one or more commercial data providers' to 'if someone steals our data and combines it with stolen data from several other sources, they have a non-zero chance of guessing your identity correctly'.
- clarry 8y ago
  > I'm not sure offhand if browsers would be passing a referer header by default, or if that could somehow reliably identify the site I'm actually visiting. If so, that'd be one valuable fact. They are passing referer unless the context is an encrypted connection and the resource is on plain HTTP. Firefox also strips out the path from the URL for third party requests, but only in private browsing mode: https://blog.mozilla.org/security/2018/01/31/preventing-data-leaks-by-stripping-path-information-in-http-referrers/ https://blog.mozilla.org/security/2018/01/31/preventing-data... I think this should be the default for all third party domains no matter what the mode. (Really, I'd rather see that header just go away.)
kekumu 8y ago
If you use a third-party, they would be acting as your data processor. You'd need to make sure you have a contract with them that ensures they're respecting GDPR as well. I agree with others that you should self-host whenever possible. It will simplify these questions and you'll be able to fully protect your users' data yourself.

ptype 8y ago

I have submitted this because it is frequent to see on HN claims that IP addresses are personal data under GDPR. I’m yet to see a good source for this blanket statement, and this link contains a more nuanced analysis, essentially saying that IP addresses are only personal data in some cases, where they can be used to identify a person (without involvement of the ISP).

lurker456 8y ago
GDPR is more recent and supersedes this.
- tjoff 8y ago
  Though the exact same reasoning applies.
- killjoywashere 8y ago
  I'm fairly certain the US legal system, when interpreting domestic cases (the purview of HIPAA) doesn't care about the GDPR. If a case crossed international boundaries, sure, but to say GDPR supersedes HIPAA is false. They apply to different jurisdictions, which are mostly, if not entirely, separate.
  - lurker456 8y ago
    Agreed, the US is more lax. I was responding to the parent comment "I have submitted this because it is frequent to see on HN claims that IP addresses are personal data under GDPR"
killjoywashere 8y ago
IP addresses are also considered PHI under HIPAA. This is new to the GDPR.
- zaroth 8y ago
  IP addresses are not themselves PHI, but the presence of IP addresses is considered to make PHI “individually identifiable”. IP addresses must be removed when you are de-identifing PHI. You also, by the way, must remove any geographic information more specific than a state, such as ZIP codes. So it doesn’t say much to include IP addresses in the deidentification list.

deleted 8y ago

[deleted]

jlgaddis 8y ago

The main takeaway (IMO) from this article is right here: > However, businesses should note that if they have sufficient information to link an IP address to a particular individual (e.g., through login details, cookies, or any other information or technology) then that IP address is personal data, and is subject to the full protections of EU data protection law.

clarry 8y ago
Can we interpret have as can obtain? Do a geolookup, you have my approximate location. Do a Google search for my IP address and you'll have my name.
- jlgaddis 8y ago
  > Can we interpret have as can obtain? From my reading, you can interpret it that way if "the website operator has a 'legal means' of obtaining access to the information". Refer to the "What makes a dynamic IP address personal data?" section of TFA. (N.B.: I am not a lawyer. Ask your doctor if taking legal advice from strangers on the Internet is right for you.)
- kekumu 8y ago
  I would. Better to be overly cautious if you're serious about protecting user data and privacy. IPs specifically are quite likely to reveal some identifying info, and it's obvious how trivial it is to find that info. Even the company itself isn't looking that info up, losing that info could expose their users.
- threeseed 8y ago
  > Do a Google search for my IP address and you'll have my name. How does that happen exactly ?
  - dylz 8y ago
    Business class internet at home often will reassign it to your full name and address, for example.

deleted 8y ago

[deleted]

Lazare 8y ago

The coverage of GDPR I've seen (and in my view, the regulation itself) has been pretty clear that data becomes covered "personal data" only to the extent that the data, in aggregate, can be used to identify a real person. So an IP address on its own is almost never personal data, because of wifi, NAT, dynamic IPs, shared devices, etc. Then again, a name is almost never personal data on its own either, "John Smith" could refer to any one hundreds of thousands or people or it could be a pseudonym and refer to literally billions of people. But if someone registers on your site, and you log the IP address and their name, you're a lot closer to persona data. Add a timestamp, and you probably can identify a real person. So if you're trying to be careful about GDPR, you should probably be careful about storing IP addresses (or IP addresses that can be linked to other bits of potentially personal data). The focus of GDPR compliance can't be on "oh this field is fine, but this field is personal data", it should be on what you're collecting in aggregate. That makes IP addresses dangerous, because they provide a lot of information that could be used to identify someone.

apple4ever 8y ago
But as the article points out, adding a time stamp only will matter if you have access to other data to map it to a real person. So based on my reading, IPs and time stamps are not PII unless you are an ISP or you link them to other PII (so still the IP and time stamps are really irrelevant because they depend on that other PII).
- shabble 8y ago
  You're unlikely to be storing only (IP, timestamp) data though. Presumably there's some additional info attached to those records that makes it useful for something. A web access-log records (ts, ip, request, ...), or maybe your application log stores (ts, ip, action, params, ...) So the information from that single source is "at time T, IP accessed RESOURCE". It's possible that's personally identifiable in context (if you have additional controls that RESOURCE can only be accessed by exactly 1 real person, etc) But say it's not. All you know is: Opaque PERSON accessed RESOURCE. if you can obtain the identifying information from elsewhere (buy, steal, etc) from ISP or whatever, you now know that (T, IP) = NAMEDPERSON. A simple lookup/matching means you know that NAMEDPERSON accessed RESOURCE. That's the new personal data. The IP isn't irrelevant, because without it, you'd have no lookup key to determine the mapping from PERSON? to NAMEDPERSON.