Google Fonts is a very suspicious “service library” allegedly meant to make it easier for developers to use fonts by referencing a stylesheet. There are thousands of fonts available but the completely hidden tradeoff is that use of any font transmits personal user data to Google, without disclosing the tradeoff to anyone involved.

A court has now ruled that users may claim damages from site operators who use Google Fonts.

Note that Google marketing doesn’t mention anything about privacy or safety when they try to pitch their product.

Making the web more beautiful, fast, and open through great typography and iconography Google Fonts makes it easy to bring personality and performance to your websites and products. Our robust catalog of open-source fonts and icons, makes it easy to integrate expressive type and icons seamlessly—no matter where you are in the world.

Continuing on that same page there are some obvious red flags (misrepresentations) that jump out right away:

First, they assert the entire experience is free and open.

All the fonts and icons in our catalog are free and open source, making beautiful typography and iconography accessible to anyone for any project. This means you can share favorites and collaborate easily with friends and colleagues. Google Fonts takes care of all the licensing and hosting, ensuring that the latest and greatest version of any font is available to everyone.

FALSE. “Fonts” is a service. You pay with your privacy and Google does not open source all the “Fonts” code, such as what’s involved in collecting and processing your personal information.

Second, they claim adding more traffic makes the web faster.

Using the code generated by Google Fonts, our servers will automatically send the smallest possible file to every user based on the technologies that their browser supports. For example, we use WOFF 2.0 compression when available. This makes the web faster for all users—particularly in areas where bandwidth and connectivity are an issue. The icon sets that are delivered by Google Fonts benefit from the same infrastructure.

FALSE. This reads to me as lying. “The smallest possible file to every user” does not make the web faster than sending no file at all. Fonts are not required to be served remotely. Google is literally saying they are slowing the web down, and trying to pivot that into a phrase of the “smallest possible” slowdown. That’s a lie. Smaller is possible.

In the FAQ provided by Google Fonts they even admit to tracking users.

What does using the Google Fonts API mean for the privacy of my users?

The Google Fonts API is designed to limit the collection, storage, and use of end-user data to only what is needed to serve fonts efficiently. Use of Google Fonts API is unauthenticated. No cookies are sent by website visitors to the Google Fonts API. Requests to the Google Fonts API are made to resource-specific domains, such as fonts.googleapis.com or fonts.gstatic.com. This means your font requests are separate from and don’t contain any credentials you send to google.com while using other Google services that are authenticated, such as Gmail. In order to serve fonts quickly and efficiently with the fewest requests, responses are cached by the browser to minimize round-trips to our servers. Requests for CSS assets are cached for 1 day. This allows us to update a stylesheet to point to a new version of a font file when it’s updated, and ensures that all websites using fonts hosted by the Google Fonts API will be using the most updated version of each font within 24 hours of each release. The font files are cached for 1 year. Google Fonts logs records of the CSS and the font file requests, and access to this data is kept secure. Aggregate usage numbers track how popular font families are and are published on our analytics page. We use data from Google’s web crawler to detect which websites use Google fonts. To learn more about the information Google collects and how it is used and secured, see Google’s Privacy Policy.

Did you catch that? First “limit…to only what is needed“.

That’s fishy.

Then “font files are cached for 1 year. Google Fonts logs records of the CSS and the font file requests, and access to this data is kept secure.” That smells rotten.

“Secure” is a relative term, whereas as compliance (e.g. GDPR) is an absolute one. Secure against whom and what?

I call BS.

This blog, for example, is self-hosted and has zero connection to Google. Yet because it runs on default WordPress and uses a standard default theme it still had embedded Google fonts and without any warning or notice to me or my blog readers that Google was tracking them.

Both my readers and I noticed this by digging into the code as well as the network traffic but you can’t expect everyone to be in the weeds, especially given Google is supposedly offering a “service”…

Thus, for the last several years, I always have had the “disable-remove-google-fonts” plugin by Danny Cooper enabled to protect privacy of my blog readers.

Improve frontend performance by disabling Google Fonts loaded by themes and plugins.

The plugin hits back on obvious lies. Improve performance by disabling Fonts. Really though… the plugin improves privacy.

Now a court in Germany has made this concern an official ruling.

Google was found on the wrong side of this issue because Fonts never should have been dragged by them into being a human tracking system.

The court ruled that penalties are owed to someone reading a site with Google Fonts since it violates GDPR, making website operators liable.

The use of font services such as Google Fonts cannot be based on Article 6 Paragraph 1 S.1 lit. f GDPR, since the use of fonts is also possible without the visitor having to connect to Google servers. RN 8

The visitor is not obliged to “encrypt” his IP address (probably means to disguise it, for example by using a VPN). RN 9

The transfer of the user’s IP address in the above-mentioned manner and the associated encroachment on general personal rights is, with regard to the loss of control over personal data, to Google, a company that is known to collect data about its users and the way the user perceives it individual discomfort is so significant that a claim for damages is justified. RN 12

Use of fonts is possible without having to connect to Google.

BOOM.

Perhaps also notable here is that dynamic IP address is ruled personal data. That surprises me a little, to be honest, because dynamic IP is meant to be privacy-preserving so it’s an indictment of Google while also pointing out technical solutions on the consumer end aren’t enough to fight surveillance.

The user thus is not obligated to increase defensive measures against Google, it is the site operator who knowingly or unknowingly works with Google who is under obligation to either remove them or pay fines for violating privacy because of them.

What is the upside, if any, to the surveillance by Google? In other words, do we know what the tracking looks like?

Google offers the public a only a very limited view into the big analytic engine and that “1 year” reference to data preservation.

It kind of begs the question if Google is calculating a 1 year change percentage whether they keep more than 1 year of data (year over year) in order to do a calculation (percent decrease versus the prior year), violating their own stated policy of not keeping more than 1 year of data?

And do you believe the following Fonts usage chart is trustworthy, or even makes sense to be generated from fonts?

What do you think Google is doing with the rest of the data collected via a totally opaque platform they fraudulently market as “free and open”? If you can’t even trust Fonts, what can you trust from Google? Does anyone really need to determine the Chrome and Linux usage on the Internet by tracking the use of Fonts? It seems incredibly tone deaf.

Buyer beware. More to the point if you’re operating any resource using the heavily tainted and opaque Google Fonts service, you may be liable in court for financial damages because violating the privacy of your readers.

Apple just announced a long list of fourteen CVE fixes in their Monterey 12.2 release notes.

Notably absent is CVE-2021-44224 (as patched December 20th, 2021 by Ubuntu).

Apache titled this flaw a “Possible NULL dereference or SSRF in forward proxy configurations in Apache HTTP Server 2.4.51 and earlier”.

A crafted URI sent to httpd configured as a forward proxy (ProxyRequests on) can cause a crash (NULL pointer dereference) or, for configurations mixing forward and reverse proxy declarations, can allow for requests to be directed to a declared Unix Domain Socket endpoint (Server Side Request Forgery). This issue affects Apache HTTP Server 2.4.7 up to 2.4.51 (included). Credits: 漂亮é¼

Running on every 12.1 macOS is a bundled httpd version 2.4.51, so I find it curious that a 2021 critical CVE still isn’t mentioned in Apple’s latest upgrade announcement. It seems macOS isn’t affected by the proxy configuration issue here, yet it still deserves some mention from Apple.

The flaw in httpd (in proxy_util.c) for this CVE is reported to be basically this one line:

url = ap_proxy_de_socketfy(p, url);

And here was the change made, to verify that the called function also finds a string (URL):

url = ap_proxy_de_socketfy(p, url);
if (!url) {
return NULL;
}

In other words a patched httpd checks for NULL in the URL, as memory reads might otherwise attempt to use an undefined NULL pointer.