Google Fonts German GDPR IP Address

I (or a lot of German people) need your help.

In Germany, more and more website operators are receiving a legal letter with a warning and are supposed to pay around €170. The problem is that it doesn’t stop there, which means that if you pay the €170, someone else can come right away and warn you again.

It’s about Google Fonts. Many WordPress websites use themes that load Google Fonts. The German court has decided that it is not allowed to send the IP address to the Google because of Google Fonts and this is a violation of the rights of the customers.

Since I run a few websites, I’m now looking for a solution, but to be honest I’m coming up against technical limits. So I want to open this thread to discuss possibilities.

I have listed issues below, I will add them to my solutions.

I can think of the following options:

1. Create a child theme and then load the Google fonts locally. (Issue: 1st 2nd 3rd 4th)
2. Service worker that rewrites the URLs (Issue: 5.)
3. Nginx rewrite, rewrite the php output and replace google fonts url (Issuing: 1. 4.)

More?

Issues:

1. If you have e.g. integrated a script (Google Maps, Recaptcha, Intercom, …) it can happen that Google Fonts are reloaded by Javascript.

2. Theme updates.

3. A lot of work when multiple customers.

4. Plugins load elements on certain pages or only later after it can happen that google fonts are loaded again.

5. Only works if the service worker is installed

I am open for any idea. It looks like Google will not fix this.

Answer

There is no easy technical fix. The only long-term fix is to review how you include any third-party content on your websites, in case this embedding causes any visitor personal data to flow to such third parties.

This is not a new development. A lot of the relevant compliance steps already entered the (German) mainstream in the early 2010s when the problem was Facebook’s “Like button”. The generally accepted solution for that is that the third party content is not loaded directly. Instead, a placeholder widget is rendered that indicates which content would be available there. Then, the user can give consent with one click and the actual embedded content is loaded.

With Google Fonts, no such consent flow is needed or appropriate. All of the fonts on Google Fonts are Open Source licensed – you are allowed to use and distribute them for free, but subject to the license conditions (like making the license notice available to users). So on a technical level, it is easy to self-host the fonts in question.

What is tricky is efficiently rewriting the requests caused by your websites to point to your own servers instead of to the Google servers. You have identified a couple of approaches and have identified their pros and cons. Some comments:

• Client-side rewriting sounds very fragile, I’d avoid it.
• Server-side rewriting can be very powerful, but would also be somewhat fragile. The main advantage of such rewrites would be that it doesn’t just handle Google Fonts embeds from your themes, but also requests inserted by server-side plugins.
• Updating the theme is the only reliable long-term solution. Creating a child theme might be a suitable stop-gap measure until the theme developer fixes the problem. Similarly, it may be necessary to temporarily modify WordPress plugins.

I think that as a band-aid, server-side rewrites will be good enough to prevent many automated scanning tools used by these cease-and-desist lawyers from sounding the alarm on your sites.

However, you have correctly identified that especially JavaScript could cause problems for achieving actual compliance. This is why you should revisit your decisions about what plugins and scripts you have integrated. Loading third party JavaScript has pretty much the same legal consequences as loading fonts from Google, so you should only do it if it’s actually necessary for your site (where necessity depends on the user’s perspective), or if the user has given valid consent. For example, you can use the placeholder widget technique mentioned above for embedded content like Google Maps or Intercom, whereas loading a Captcha may indeed be strictly necessary on some pages.

For testing these issues, I’d recommend installing Firefox with the uBlock Origin addon, and setting the addon to hard mode. This will block all third-party/cross-origin requests. You can then allowlist those domains that are under your direct control, or are provided by your data processors (who are contractually bound to only use the personal data as instructed by you, and are considered first-party for GDPR purposes), or domains for which you have a legal basis to share the data (e.g. a “legitimate interest” to load stuff that is strictly necessary for your site to work, or to investigate what requests are made when the user gives consent).