The issue of "data processing in insecure third countries" has caused massive legal uncertainty among companies. If one is 100% accurate, then cloud services from Amazon or Microsoft should no longer be used at all, with unforeseeable consequences for domestic companies and administration. However, there is no reliable case law on this, and so for the time being it will probably remain the familiar maneuvering around this issue.
While this article cannot provide an answer to the question of what is allowed and what is not, it can help you prove said data processing in insecure third countries on a website, which is also not always easy.
Data Transfer Criteria
If I use a service like Gmail, and it stores my emails on a server in the US, it is quite obviously processing personal data abroad.
However, the term must be understood more broadly, because each time a server is contacted by a network request, its own IP address is transmitted, which is considered personal information. Because of the CLOUD act , it doesn't matter whether the server itself is in the USA . As part of a website check, you must therefore examine the following three aspects:
Hosting of the website
Are any of the companies involved in any way with the hosting infrastructure based in an insecure third country? Or is the server that delivers the website located in an insecure third country? You can read more about how this verification works below.
Operators of external services
Analogous to the hosting of the website, the question arises for all integrated services: where is the company that operates the service headquartered? And additionally: is the service's web server located in an insecure third country, or are companies operating the infrastructure in an insecure third country?
Determining the headquarters of the company is not a technical task, a look at the imprint or (if not available) a search through Google & Co. is sufficient for this. You will learn an example of the technical check below.
Recipients of form data
If data is sent via a form, then it may go to an external service - the same questions as above then apply to these. We will describe how this check works in a separate article (which will surely appear soon 🙂
Check server location and infrastructure
For each of the three aspects mentioned above, the infrastructure can be checked using the same methodology. To prepare, we need to consider in advance the options that can be used to run current web applications and the integrated external services.
On-Premise-Hosting
"On-premise" hosting is website operation in a data center. The location - or at least the country - of the web server corresponds to that of the data center, and usually also that of the provider. Of course, "web server" does not mean a single computer, but the entire connected infrastructure (router, load balancer, web server cluster, etc.).
In most cases, a content management system (such as WordPress) or a store system is installed on the provider's servers. Most companies operate their website in this way, including decareto.
Platform as a Service
For several years, "Platform as a Service" (PaaS), also known as cloud hosting, has been very popular with both website operators and external service providers. The reason is the great flexibility and easy scalability of this method. The large providers such as Amazon AWS, Microsoft Azure or Google Cloud Platform operate data centers worldwide, and enable high-performance and fail-safe operation even with very large numbers of visitors.
In terms of data protection, however, this option is at least not completely unproblematic, since both the cloud provider's data center and its headquarters may be located in an insecure third country. Since almost all providers are based in the USA, the latter is even very likely.
Software as a Service
Instead of hosting software like WordPress in a data center themselves, companies can now turn to website building kits like Jimdo or cloud store systems like Shopify. These companies usually run their SaaS application on rented infrastructure, such as that of Amazon AWS or Google. So the location of the web server, the headquarters of the SaaS company and the headquarters of the infrastructure operator are relevant here.
Content-Delivery-Networks
In order to operate a high-traffic website or service in a more fail-safe, faster and cost-effective manner, companies often use so-called "content delivery networks" (CDNs) from companies such as Akamai, Cloudflare or Fastly. These have a large number of caching servers in operation worldwide.
When a user accesses such a website, he does not establish a connection to the actual web server, but to a server of the CDN. This server has loaded the data from the origin server in advance. This reduces the load on the origin server and allows data to be delivered more quickly to users in the country in question.
CDNs can be combined with all three variants described above, and many SaaS providers prefix their software with a CDN. For example, the German provider Jimdo uses the infrastructure of Amazon AWS and also the CDN of the American provider Fastly.
However, they are also a potential data protection risk, which became apparent when the use of Cookiebot fell into disrepute because the (Danish) product used the American CDN service provider Akamai (see below).
How to determine server location and provider
It is remarkably easy to get information about a web server. All you need is the IP address of the server - the rest is done by online services that provide corresponding databases. These services are used, for example, for personalized online advertising or fraud prevention - the most famous provider is Maxmind, but there are a large number of such companies.
To find out the IP address of the server, proceed as follows:
- Open the website you want to examine, then open the Chrome Developer Tools Network tab.
- Right click on the columns and select “Remote Address”
- Then this column shows the IP address of the server for each individual request. The “port number” is displayed after the colon, it is 443 for encrypted and 80 for unencrypted connections. However, it is not relevant to the investigation and can be ignored.
- For our server decareto.de the IP address is 83.138.88.57
Online databases for analyzing IP data
There are a number of services that provide further information on an IP address. For occasional online research, they are usually free of charge. In the next step, we will use the service "ip-api", which is available at ip-api.com.
Enter the IP address in the input field and confirm by clicking on “Search”. You should then see the following:
- Under city and country you can see the location of the server, in this case Bremen.
- Under isp you will see the name of the hosting provider, “hostNet”. As mentioned above, this is on-premise hosting with a German provider.
- The org field sometimes contains additional information, but not in this case.
Let's examine another website:
- The developer tools show the IP 54.171.81.156 for this
- Input at ip-api.com gives the following result:
- country: Irland
- isp: Amazon.com, Inc.
- org: AWS EC2 (eu-west-1)
This is apparently cloud hosting with Amazon Web Services. A look at the request in the network tab gives additional clues:
- Two domains come up very frequently: assets.jimstatic.com and u.jimcdn.com. When you look at the first domain in the browser, you don't see much, but enough to guess the company behind it:
This website uses the German website builder Jimdo, which in turn (we also mentioned this above) runs on the Amazon Web Services infrastructure. The server location is Ireland. However, Amazon is a US company.
The Cookiebot problem
On December 1, 2021, the Wiesbaden Administrative Court had ruled that the use of the Cookiebot consent tool is not permissible because it transfers data to unsafe third countries. Although the ruling was overturned by the Administrative Court of Hesse, it has caused quite a stir in the data protection community because it highlights the problems associated with hosting infrastructures abroad.
The company Cookiebot is based in Denmark. So what was problematic about using the software? And are other services from European providers possibly also affected? To find out, let's open the website www.bkk24.de, which uses Cookiebot, and first identify the network requests that belong to the Cookiebot service.
- Judging by the domain, the request https://consent.cookiebot.com/uc.js shown in the screenshot belongs to Cookiebot. We save ourselves further research in this regard...
- The server consent.cookiebot.com has the IP address 2.16.204.144
- We check them with ip-api.com and get the following result:
- city, country: Hamburg / Germany
- isp: Akamai Technologies
So the web server belongs to the US-American content delivery network Akamai. Problematic from a data protection point of view, even if the physical location of the server is in Germany.
This is hosting as described above in the section "Content Delivery Networks". Unfortunately, the CDN shields the origin server, so it is not possible to find out where Cookiebot is actually hosted. It could be servers in Denmark, but it could just as easily be an infrastructure like Amazon Web Services.
Who else does this affect?
One might now think to take a closer look at the hosting infrastructure of other European services, for example Usercentrics. The German top dog in consent management merged with Cookiebot in 2021, maybe they use Akamai there too?
The following website uses Usercentrics, and we recognize the corresponding requests from the service in the network tab:
- In the screenshot, the arrow points to requests from two different domains that apparently belong to Usercentrics: api.usercentrics.eu and app.usercentrics.eu.
- For example, let's examine api.usercentrics.com with the IP address 35.241.3.184
- We check them with ip-api.com and get the following result:
- city, country: Kansas City / USA
- isp: Google LLC
- org: Google Cloud
So Usercentrics runs its product on Google Cloud Platform infrastructure, and the server location is in the USA. Analogous to Cookiebot, one must conclude that this is potentially problematic from a data protection perspective, especially since Usercentrics is supposed to help comply with data protection guidelines.
Author: Eckhard Schneider
