Hi. It has come to our attention that the Bitmovin player makes an endpoint call to https://licensing.bitmovin.com/licensing for validation. The POST request is done to a domain outside of the EU (US).
According to GDPR, IP addresses are considered “Personal data”, and making this request from a client’s browser could be in violation of GDPR.
I’m wondering if you have faced this topic in the past. Is there a solution? Am I missing something that makes this a non-issue? Thanks a lot
Hello @matias.berrutti ,
thank you for your question.
This is actually not an issue as the endpoint you are looking at is actually inside the EU.
Our player licensing is using the Google Global Load-Balancer infrastructure to route all requests directly to our Datacenter in Google Cloud in St. Ghislain, Belgium, Europe.
There the licensing requests are processed and all our licensing backend infrastructure is hosted never leaves the EU.
The datacenter region we are using is europe-west1 which you can read up all about on Regions and zones | Compute Engine Documentation | Google Cloud
I hope this answers your question,
greetings Daniel
Thanks Daniel!
That’s great news.
I will communicate this to my PM.
Sorry I haven’t replied before, I didn’t get a notification of your reply.
Thanks again.
Matias
Hey Daniel,
Just a small follow up question, I did a small test with NS Lookup here:
https://www.nslookup.io/domains/licensing.bitmovin.com%2Flicensing/webservers/
It seems that this request resolves to the following IP, 35.227.229.24.
So the first processing of the request is done on Google’s load balancer that is located in the US.
Could you confirm that this is the case?
For what is worth, I believe your comment that you don’t do any processing outside of the EU, but I’m afraid that some of our customers wont be so happy with this reply 
Thanks a lot.
Matias
Hi Matias, great question - please let me explain.
The IP we are using is a Global Anycast IP offered by the Google Global Loadbalancer Service. This means that any traffic sent to this IP address will enter the Google GCP Network at the closest available Google Cloud Point of presence (see the full list here) from the point of Origin and then traverse the Google Network to be routed to our Servers in Belgium within the europe-west1 region. This topology enables us to provide a extremely fault tolerant, scalable service that has great latency from anywhere around the world because we leverage the Google Backbone.
This GCP Blogpost explains this in more detail: https://cloud.google.com/blog/products/networking/understanding-google-cloud-network-edge-points
While in transit traffic is always encrypted using TLS end to end and is only terminated inside of europe.
An example: If I run a traceroute to our licensing IP address (35.227.229.24) from our Klagenfurt Office the requests will be routed to the closest GCP ingest point in Munich, Bavaria and from there be directly routed to Belgium - minimising round trip time for my request.
traceroute to licensing.bitmovin.com (35.227.229.24), 64 hops max, 52 byte packets
1 172.27.238.1 (172.27.238.1) 4.812 ms 4.277 ms 5.049 ms
2 192.168.1.1 (192.168.1.1) 4.946 ms 3.935 ms 4.282 ms
3 80-80-246-1.stat.stw-net.at (80.80.246.1) 4.139 ms 5.303 ms 4.780 ms
4 80.80.255.14 (80.80.255.14) 4.051 ms 8.053 ms 4.380 ms
5 80.80.255.18 (80.80.255.18) 5.420 ms 6.719 ms 3.913 ms
6 80.80.255.50 (80.80.255.50) 4.396 ms 5.482 ms 9.002 ms
7 185.208.12.114 (185.208.12.114) 4.467 ms 10.166 ms 7.212 ms
8 ae2-0-r62.equ.muc.nextlayer.net (92.60.2.165) 15.652 ms 13.540 ms
ae1-0-r62.equ.muc.nextlayer.net (92.60.2.103) 15.354 ms
9 ipv4.nextlayer.muc.de.as15169.google.com (185.208.12.95) 14.976 ms 13.440 ms 14.599 ms
.... (more hops but this is internal routing inside the Google Network)
I asked a colleague to run the same traceroute from India and this is the output that routes entirely differently
traceroute licensing.bitmovin.com
traceroute to licensing.bitmovin.com (35.227.229.24), 64 hops max, 52 byte packets
1 192.168.1.1 (192.168.1.1) 8.657 ms 4.941 ms 11.737 ms
2 210.18.139.1 (210.18.139.1) 12.059 ms 2.835 ms 5.925 ms
3 202.88.152.73 (202.88.152.73) 5.801 ms 2.848 ms 3.145 ms
4 * 202.88.167.130 (202.88.167.130) 36.444 ms *
5 142.250.172.12 (142.250.172.12) 23.850 ms 5.125 ms 6.665 ms
6 216.239.43.133 (216.239.43.133) 5.603 ms 3.875 ms
216.239.43.131 (216.239.43.131) 3.234 ms
7 142.250.235.105 (142.250.235.105) 3.983 ms
74.125.252.215 (74.125.252.215) 4.371 ms
142.250.228.245 (142.250.228.245) 4.448 ms
8 24.229.227.35.bc.googleusercontent.com (35.227.229.24) 3.722 ms 5.500 ms 4.350 ms
As you can see the packets take a completely different route through the Internet based on where they originate.
Also keep in mind that especially with fully software defined networking infrastructure like Google’s (or any sufficiently modern networking) none of the IP geolocation tools out there are really accurate or meaningful because Google obviously doesn’t/can’t really disclose which IP is mounted to which router/switch around the world at any given time. Especially given the IPv4 shortage IP addresses very frequently move around.
I hope this helps alleviate your concerns - the TLDR is that regardless of the way that the data is traveling, our Licensing Backend is only hosted in europe-west1 and the data is not being transferred to anywhere.
Aside from the technical explanation above please also refer to Standard Contractual Clauses (SCCs) that we have signed that govern our usage/governance of any data being transferred and which serve as the legal basis for any such transfer.
greetings Daniel
1 Like
Hey Daniel,
Thank you very much for your thorough explanation.
I will forward this to the parties that requested this information and I will mark this as a solution.
Again, thank you so much.
Have a great day!
Matias
1 Like
This topic was automatically closed 60 minutes after the last reply. New replies are no longer allowed.