[lmkg]

Court rulings in the EU have found that US law is not compatible with GDPR: US lets law enforcement have unfettered access to the data of EU residents, with no restrictions or redress mechanisms that satisfy the EU court.

This means that sending data from the EU to a US company is almost always a GDPR violation. There are a few nuances to this which are very important.

- The US CLOUD Act gives US law enforcement access to data stored in other jurisdictions. This means that locating the servers in the EU is not sufficient. Nor is operating via an EU subsidiaries.

- IP address counts as personal data, as does pseudonymized identifiers.

The two of these combined mean that GDPR forbids you from having your users connect to Google servers. This is why Google Fonts is straight forbidden, and why most installations of Google Analytics are forbidden. Also the use of basically anything from Google, Azure, AWS, Oracle, Facebook, Akamai, etc except when routed through an EU proxy which obscures the user's original IP address.

[spiffytech]

In case it's not clear, this "sending data to the US" thing also means storing data in the US (because you have to send it there).

The FAQ for the Schrems II ruling makes it clear that SCCs and BCRs aren't a basis for sending data to the US (BCRs are still valid for other regions that haven't received an unfavorable adequacy decision).

https://edpb.europa.eu/sites/default/files/files/file1/20200...

As far as I can tell, nobody's enforcing the rules about where you store your data right now (as distinct from sending user data to 3rd parties, like the Google Fonts thing).

[jiveturkey]

> sending data from the EU to a US company

1. not data. Personal Data. of course if you know you know, but threads like these are rife with non informed readers.

2. nothing to do with the geo residency of the company. it's about sending the data to the US (or most non-EU countries). Even an EU company can't send the data to the US absent various agreements.

3.You are way overstating the violation part. It's very easy to be able to send the data and be compliant.

[lmkg]

> not data. Personal Data.

That's fair. Although a lot of data can become personal data if you're not careful.

> it's about sending the data to the US (or most non-EU countries)

Disagree, the United States is in a worse condition that most other countries. Even in countries without an adequacy decision, you can usually satisfy GDPR by incorporating SCCs into your contract. A US company cannot comply with GDPR because they are beholden to US laws which require them to violate the terms of any contracts they sign protecting the data privacy of their users (according to the CJEU).

> It's very easy to be able to send the data and be compliant

Probably depends on your context. Something like, say, sending a pile of data over to GCP to train an ML model on? Probably easy to comply. Front-end dev work? Anything that makes the user's device connect to a Google URL is forbidden, since that's sending personal data (IP Address). The higher-level your framework, the more care it takes to avoid some dependency doing this behind your back.

[herbstein]

This is my understanding too. Meaning, there's a huge backlog of compliance issues at so, so many companies.