Hosting Google Fonts Locally For GDPR Compliance
On episode 607 of the Syntax podcast, Wes and Scott interviewed the co-founders of Termageddon, a consulting company that helps websites create and maintain compliant policies. One of the topics that Termageddon has discussed in the past is Google Fonts. Google Fonts - when served from Google's APIs - have been ruled not GDPR compliant. However, if you serve Google Fonts up locally, they are GDPR compliant. As such, I've started to host them on my own web server.
To be honest, I know very little about how Fonts work. That was kind of the magic of using Google Fonts - they just worked without any additional effort. As such, I didn't really know how to move forward with hosting fonts myself.
Thankfully, Martin Schaible pointed me to Google Webfonts Helper by Mario Ranftl. This website hand-holds you through downloading the desired font files and generates both a ZIP file (of the optimized font selection) and a CSS snippet that you can apply to your own site.
I believe I still have some changes to make (beyond just fonts) to bring my site into full GDPR compliance. But, this is now one less thing to worry about.
Serving "Local Fonts" Through Cloudflare CDN
CAUTION: I am not entirely sure if serving the fonts through a CDN (Content Delivery Network) keeps me in compliance? In their "Trust Hub", Cloudflare talks about being GDPR compliant; and, about being a "privacy-first company." As such, I hope that serving the font files through the Cloudflare CDN doesn't negate my efforts.
Static assets, that I serve up through the CDN, are hosted on a different domain. My blog is at bennadel.com, and my CDN domain is at bennadel-cdn.com. Using a different domain holds a few advantages; but, when it comes to Fonts, it is a bit problematic. When I initially pushed the change to my production server, I started seeing CORS (Cross-Origin Resource Sharing) errors due to loading font-files from a different host.
To fix this, I went into my Cloudflare Rules, and added a Transform Rule that sets the Access-Control-Allow-Origin HTTP header in the outbound response for font-related requests:
ASIDE: I was already injecting this CORS header for my compiled JavaScript files. As such, I just appended a condition for my font files.
I believe that the * here is the lazy man's approach to Access-Control-Allow-Origin. But, I didn't want to take the time to test my root domain.
Reader Comments
One of the other things that I've done recently for GDPR compliance is dropping Google Analytics for tracking. Pre-GA4, Google Analytics was not GDPR compliant. Google claims that GA4 is compliant; but, the co-founders of Termageddon are waiting to see how GA4 pans-out legally.
This doesn't make much sense for lots of reasons. The regional German court is not the EU court or even the ECHR, so how can it apply to the rest of the EU? The German court said Google Fonts isn't GDPR compliant because it collects IP addresses (without permission). On that basis, every CDN would break GDPR including Cloudflare who state they log IP addresses. That would put 7.5 million websites out of bounds to citizens in German (and arguably all within the EU, but as I said earlier the court ruling is from a regional court in Germany).
Because CDNs span so many sites they'd be able to track each users browsing history to an extent. They wouldn't necessarily be able to identify you by anything other than an IP address, but what if an ecommerce website that uses the same CDN includes your email address in a URL, that might get logged by the CDN and suddenly every website you've visited and various activities on the sites become associated with that email address. But it's only illegal if it's Google Fonts and you live in Germany. 🤷♂️
@Gary,
To be honest, I don't really understand how this all works! I agree though, it seems like something about it is "not right"; and, maybe in the long run, things will starts to find more balance? I don't know.
Post A Comment — ❤️ I'd Love To Hear From You! ❤️
Post a Comment →