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?
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.
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.
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'.
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...
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.)
I suspect it's sufficiently ingrained in existing apps to make it hard to deprecate completely, but something like the path stripping might be a decent compromise.
For cross-origin requests I think there's also a mandatory 'Origin:' header that would identify at least the domain (but not path) a user request was referenced from.
I used to use a firefox addon called RefControl but IIRC it was a casualty of the quantum/webextensions transition. uMatrix has a basic referer spoofing capability, but it's all or nothing for a particular site/scope.
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.