Fonts and Trackers

WordPress Fonts and Trackers

Sexy women by large letter blocks that spell pixabay

Most WordPress themes, including the default themes, make use of Google Fonts. This results in tracking information from your users being sent to Google.

I was not fond of this before, but with The CLOUD act, it is particularly scary. The CLOUD act literally turns third party trackers into a source of government surveillance on your users. So much for the fourth amendment.

The fonts offered by Google Fonts are very often very beautiful and they do enhance what a WordPress powered website looks like. As such, there are two logical reasons why a sex worker would want a solution that allows use of the fonts but without tracking:

  1. To avoid the privacy of their users being compromised to the government, as well as to Google.
  2. To allow the website to render as intended for users (like me) who block third party trackers.

Fortunately every font in Google Fonts has a liberal license, usually SIL Open Font License, that allows the font to be hosted wherever without a license cost. So it usually (perhaps always) will be possible to host the desired font on a font server that does not track.

Solving the problem in WordPress however was still not easy. Virtually every theme that makes use of Google Fonts does so with the add_query_arg() and/or esc_url() functions, but those functions do not have any hooks that allow modification of their output. Honestly it probably is safer that those function do not have any such hooks, otherwise plugins would do dangerous things with the hooks that open up XSS vulnerabilities. So I really can not fault WordPress for not including those functions in the functions that do have filter hooks.

Without callback filter hooks, all the solutions I came up with that did not involve theme modification were so hackish that I did not believe they should be used. So the solution I did come up with either requires theme modification by the blog administrator or cooperation from the theme developer. I am attempting to get my solution into WordPress core to make cooperation from theme developers more likely.

Step One: PHP Class for Generating Google Font Query

The technical way in which Google Fonts are used, the web page asks the font server for a CSS style sheet that has the actual font definitions. This is done with a standard <link /> tag in the <head /> section of the web page.

The link tag queries fonts.googleapis.com with GET parameters defining what font families it wants and what variants of those font families it wants, and usually what language ranges it wants character coverage in.

Even though it seems like the vast majority of themes make use of Google Fonts, WordPress Core does not provide a function library to generate the link tag, that is up to the theme developer to do and unfortunately that means the theme developer hard-codes fonts.googleapis.com into the theme code.

To solve the problem of tracking through Google Fonts, a tool needs to exist for theme developers that builds the link for them but at the same time gives the blogmaster the ability to define an alternate source of the fonts that does not track.

So I created such a tool:

AWMFontBuilder.php

It must be loaded before the theme loads, so until it is part of core (WordPress Ticket 43898) the code from that github gist needs to be put into wp-content/mu-plugins where it will always load and always load before regular plugins and themes load.

Please note that just because I have created a ticket at WordPress.org asking for the code to be added to WordPress core does not mean it will be. In the past (as in several years ago) there were several other changes I wanted to see in WordPress core and they (the devs) wanted nothing to do with them. That is one of the reasons I stopped having anything to do with WordPress until recently, they (the devs that have the power) do not like people who think the way I think. That is the very clear impression I got. I get it, I’m strange. But anyway…

It has been several years, so maybe the WP dev attitudes have changed and maybe both GDPR and the Facebook tracking scandal are enough to make them realize that webmasters who want less tracking should be able to achieve that. So maybe this feature will be added. Also, the PHP class I wrote makes it easier to properly use webfonts, so it has more benefits than just giving the option of better privacy.

For themes that use that class, using an alternate to Google Fonts is as easy for the blogmaster as adding a single line to their wp-config.php file defining what the alternative is.

Step Two: Theme Updates

The php script above does absolutely nothing if the code for the theme does not use it. For most themes, that is actually pretty easy. Below is the patch I made to the Twenty Fifteen theme:

twentyfifteen.patch

The functions.php file was the only file that needed patching, and that was to define a new function when the needed class is present and then use the new function instead of the old when the new function is defined. That keeps it backwards compatible, so the old way is still available should the php class that defines the new way be removed.

Getting theme developers to make that change will be a lot easier if the AWMFontBuilder class is part of core.

Until then, their only option is to include the AWMFontBuilder class in their theme source as patching their themes to use AWMFontBuilder is pointless without the class.

What I can do is patch various themes to use it for blog administrators who will put the class in their wp-content/mu-plugins directory, but for this to really see widespread use, the class needs to become part of core.

Step Three: Mirror the Desired Fonts

Mirrors of Google Fonts have existed in the past, and there probably are others now, but the sheer size of Google Fonts is huge. I believe it is over 300GB of data. The existing mirrors very well may also track.

So for Step Three I have created a simpler solution, code for a mirror that only mirrors what is really needed, and in a different way.

The project is live and working and in use with this blog, the github: https://github.com/AliceWonderMiscreations/FlossWoff2

Unless I am experimenting with a theme I have not yet patched to use that mirror, chances are the text you are reading right now is being rendered using a font served from fonts.trippyid.com which is the trackerless font server I have set up. You can check by highlighting some text, right clicking on it, and choosing “Inspect Element”. Then look at the font for the text. It should tell you where it is being served from.

Of course if you happen to have the requested font installed on your system, your browser might detect it and use it instead.

My font server is compatible with the Google Fonts query string, but it does things a little differently. Google over-complicates things. All queries for a CSS file defining a font goes to a file called /css on their server, with two GET parameters that control how the generated webfont style sheet is generated. Google also looks at the User Agent string the browser sends to determine how the CSS is generated.

Here is how I am doing things:

Webfont Format

First of all, I simply am not going to support all formats of webfonts. There are currently four types of webfonts currently in use:

  1. TTF (TrueType Font) – This is the largest file size option, TTF Fonts were not designed to be used as web fonts. The format though does however have the broadest browser support.
  2. EOT (Embedded OpenType) – This is a proprietary webfont format invented by Microsoft. Only Internet Explorer supports it. Smaller than TTF, but still not a good choice. Edge does not support it.
  3. WOFF (Web Open Font Format) – A much improved webfont format developed by┬áJonathan Kew, Tal Leming, and Erik van Blokland. It is supported just about everywhere.
  4. WOFF2 (Web Open Font Format 2) – An update to WOFF with better compression, the improvements are largely the work of Google. It is almost as well supported as WOFF.

For my mirror, it will only care about WOFF2. That means no support for Internet Explorer but Internet Explorer only receives security patches, it is an end of life browser. It also means no support for Safari on OS X running El Capitan or older, but El Capitan probably has less than two years of support left. It also means no support in UC Browser but UC Browser is a security nightmare no one should be using anyway.

So only WOFF2 format needs support.

Font Variants

With respect to the Google Fonts query for Font Family, Google Fonts allows you to specify what weights are desired and whether or not you want italic or upright variant.

My mirror software simply will not give a shit about the font weight or variant. You ask for a family and the generated CSS file will simply have every available font in the family defined. The browser only downloads a web font that it needs, so it does not hurt to have definitions for all variants in a family. Honestly I am not sure why Google doesn’t do that too, it makes things easier for webmasters if they do not have to worry about defining what variants they want.

Character Support

Many fonts have support for a wide range of character glyphs from many different languages. This is very nice, but it also makes the font size really large. Does the browser really need to download glyphs that include Greek, Hebrew, and Cyrillic glyphs for a page that only uses Latin characters?

Historically the way Google supported smaller font downloads was with the subset GET parameter. Different font files with different character sets would be served depending upon what was in that parameter.

Now, CSS allows the definition of Unicode Ranges when defining a webfont, and it has very wide browser support. Every browser that supports WOFF2 also supports Unicode Ranges.

What Google currently does when it detects a browser that supports Unicode Ranges, and what I plan to do with every browser, is simply ignore the defined subset parameter and serve a CSS file that defines small fonts by unicode range. The browser then will download the specific small fonts it needs to render the glyphs that need to be rendered.

However during initial development, my font server will just serve a single font for each weight and variant that covers every glyph the font supports. That is a larger file, but I have to research the best way to split a font up by unicode ranges.

Available Fonts

There is just no practical way to host every available font. The plan is to host the fonts I know are commonly used, and have the server notify me when fonts are requested that it does not have so that they can be added. That will cause a several day delay from the time a blogmaster wants to use a font that the mirror does not have and when that font will actually be available.

Covering Costs

Bandwidth and data space is not free.

The code for my font server will be open source for anyone who wants to run their own copy of it at their own expense, but for those who wish to use the copy of it I run, I will probably charge a flat rate of $25.00 a year. Sure they can use Google Fonts for free, but with Google Fonts it isn’t really free – you are trading the privacy of your visitors in exchange for it, and as more and more tracking abuses hit the news, people are becoming more and more aware of the dangers of the tracking.

-=-=-=-=-=-

Well, that’s the plan.

Step One is done, Step Two is being done on a per-theme basis. Step Three is going to take a little time.

Anonymity protected with AWM Pluggable Unplugged