Basically, the EU has put up a legal firewall between the US and the EU. Somehow this hasn't been realized fully or openly talked about, the the implication of their law is very clear.
These laws don't bind individual citizens, but companies offering services.
One might however ask, whether EU ISPs are allowed to route to U.S. as that passes IP addresses to U.S. companies. Maybe if they implement NATing?
Right. EU companies whose websites are accessed by individual citizens and usually have assets stored by US companies, such as CDNs.
As far as I know, it’s only one German court which once considered that an IP address was PII in a specific case. There is nothing in the law that explicitly says that IP addresses are PII.
I think you might be confused about the implications the German ruling has because you are from a common law country. One court ruling something doesn’t make it the law in Europe.
CJEU ruled back in 2016 that IP address is personal data if provider has legal means to identify the person. This includes, as example that was given in the case, laws that give means for service provider to identify the users in the case of cyber attack by requesting help from other authorities.
This ruling is from before GDPR and relates to the older Data Protection Directive, but the relevant chapters are largely same (GDPR mostly increased the explicit scope).
Ruling: https://curia.europa.eu/juris/document/document.jsf?docid=18...
The "tl;dr" parts are 30 (the question) & 47-49.
The old directive: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CEL...
> anyone in the EU is not even allowed to connect to any website owned by a US company
This is blatantly false, of course you are allowed to connect to non-EU websites even if the IP address could be PII in some circumstances. It's the service providers problem to manage the data they collect in legal way.
For users with accounts the standard ToS can handle it.
It makes sense to not store if you're running some kind of privacy service.
Same goes for credit card numbers, as an aside, I saw a credit card number being hashed in an app I was consulting on once... don't do that. Rainbow tables are stupid simple on inputs that small.
Everyone who's mindful of site visitor's privacy.
> How are you supposed to handle abuse or performance issues a visitor might have?
How does a static website handle those issues?
... you've developed a warped default of what a website is.
> Or perform analytics?
You can base your analytics on voluntarily provided information from users. Or just, like, _not_ do them.
There is such a thing as "legitimate interests" in the GDPR. Storing certain IPs specifically as a measure against spammers and botnets should be fine, as long as that's really all you do with the data.
> Or perform analytics?
This is the heart of why the GDPR exists. You are not allowed to collect and analyse personal data about your users without a legitimate reason or their consent (a legitimate reason is not "it pays our bills"). Either ask the user for permission or only store aggregated data.
Most companies just store a ton of data about users without having any clue what to with it, "just in case". If you collect data for specific purposes, you don't need it to necessarily include any personal info ("how many users clicked the red button instead of the blue one" doesn't require any PII, for example).
Ie. logs should be ok if its to combat DDOS and the like (for a limited time, ie 24h), but not for advertising purposes.
https://www.cnil.fr/sites/default/files/atoms/files/decision...
The law doesn't care what format that this information is stored in.
The limitations are on the parties capturing the data, not on the person whose data it is.
Well, it's certainly not this:
> anyone in the EU is not even allowed to connect to any website owned by a US company
(Note also that YouTube does not actually use a streaming protocol, but replicates some features of streaming protocols like bitrate adaptation by downloading by chunks over HTTP(S).)
----
Also maybe how VLC is illegal to use as is in countries enforcing the DMCA or MPEG licenses :
https://wiki.videolan.org/Frequently_Asked_Questions/#What_a...
How can an IP address _not_ be PII?
NIST defines [1] PII as: "Information that can be used to distinguish or trace an individual’s identity ... either alone or when combined with other personal or identifying information..."
So it's not some EU caprice.
[1] : https://csrc.nist.gov/glossary/term/personally_identifiable_...
Oh it was. I had this conversation sooo many times. Each time response was: everyone is doing it, we will just wait and see :facepalm:
(this is also the argument around cookie consent: yes, the browser chooses to accept the cookie. users don't really get an opportunity to refuse them, though. So "the browser accepted the cookies" is not sufficient consent, as far as the EU is concerned)
You don't have to make a direct TCP/IP connection for two people to communicate. We had systems like Usenet and UUCP that replicated data through a series of servers. Even today, when you use email, you talk to your email provider who talks to the recipient's email provider, and they have no need to share your personal IP addresses in the process. Some providers used to include this in Received: headers, but many today do not, rightly seeing it as a privacy concern. And even on HTTP we had (and still have, in some cases) mirrors, where legally-unrelated entities host copies of each others' data. Someone in the EU can visit http://ftp.icm.edu.pl/pub/linux/Documentation/ and never have their connection known to the US-juridiction host of TLDP.
It is both socially sensible for these providers to consent to sharing their own infrastructure IP addresses with other providers (but not share their customers' IP addresses) and legally practical for them to make that consent under the GDPR.
Why should it be the case that when you visit my personal website, which I happen to self-host, I have access to your IP address? I don't want that information. I don't even get that information when using higher-level services like Hacker News or Twitter or GitHub, even though those services operate over HTTP. It's weird that I get it, honestly.
I understand there's a huge planetary investment in HTTP, and so the collision of abstractly-reasonable privacy rights with that reality is an extremely hard engineering and policy problem. But that doesn't make the privacy rights unreasonable.
So when you misbehave, I have the means to block you in particular.
It might be meaningful under the model of direct HTTP, where you could be DoSing me or trying to exploit my web server. But if you don't contact me over HTTP, then that problem doesn't arise. There's no meaningful concept of blocking people from a Usenet post I write. Even for indirect HTTP, I don't need to block people from my GitHub Pages or from my HN comments. They're public.
If I add dynamic feature like a comment system or discussion forum to my website, then it becomes meaningful, but also at that point I can implement a way for you to consent to sharing your IP address with me as part of signing up.
What’s what with the internet is that it allows both types of models, and both are widespread and actively used today. It wouldn’t be hard for e.g. GH to run EU servers and manage mirroring all content and static sites so that traffic is roughly region local. I wouldn't be surprised if they did this to some extent just for efficiency concerns irrespective of any legal ones.
You also seem to be conflating TCP and HTTP.
In fact I think we do use the term "self-host" in exactly that way when talking about "self-hosted newsletters." I can (and do!) run a newsletter where I generate the HTML and the MIME document locally, find an SMTP provider of my choice, and instruct it to directly mail recipients. I maintain the mailing list (in a text file in a Git repo) and pass it to my SMTP provider every time I do a mailing, and people contact me directly to sign up. I could also use Substack/Tinyletter/Buttondown/etc., which would have various advantages and disadvantages; the hosting provider would handle most of this for me, including maintaining the list of subscribers. You can also talk about "self-hosted Mailman," etc. In these cases, the self-hoster sees the email addresses of subscribers but not (necessarily) their IP addresses.
I don't think I'm conflating TCP and HTTP. NNTP, UUCP, and SMTP all use TCP, but they're designed in a way that doesn't have this property. In fact it's not even HTTP per se that's a problem. It's mostly about what I called "direct HTTP" - though you posted your comment to me over HTTP, there's no HTTP (nor TCP) connection to me.
(Also other comments claim that the CLOUD Act means that if GH the US entity runs EU servers, that doesn't actually solve the problem - it'd have to be a non-US entity not subject to US jurisdiction. That's why I think the old-school-web model of mirrors is a better example; they're generally run by universities or other entities with no legal relation to the site they're mirroring.)
It is illegal to have source ip address in EU based smtp relay?