Perpetual IT

Typefaces can be a tricky business, both technically and legally.

Before word processors, laser printers and digital publishing, printed materials were quite literally “set in metal” (or wood), with typesetters laying out lines and pages by hand, using mirror-image letters cast on metal stalks (or carved into wooden blocks) that could be arranged to create a back-to front image of the final page.

The laid-out page was effectively a giant stamp; when inked up and pressed against a paper sheet, a right-way-round image of the printing surface would be transferred to the page.

For books printed in Roman script, typesetters kept multiple copies of each letter in separate pigeonholes in a handy tray, or printer’s case, making them easy to find at speed. The capital letters were kept in their own case, which was placed by convention above the case containg the small letters, presumably so that the more commonly-used small letters were closer to hand. Thus capital letters came from the upper case, and small letters from the lower case, with the result that the terms upper case and lower case became metaphorical phrases used to refer to the letters themselves – names that have outlived both printers’ cases and movable type.

Getting the right look

Designing a typeface (or “font”, as we somewhat inexactly refer to it today) that is both visually appealing and easy to read, and that retains a unique and attractive look across a range of different sizes, weights and styles, is an astonishingly complex task.

Indeed, although the digital age has made it easy to create new fonts from scratch, and cheap to ship them as computer files (another physical document metaphor that has survived into the computer era), designing a good typeface is harder than ever.

Users expect the font to look good not only when scaled up or down to any size, including fractions of a millimetre, but also when displayed or printed as a collection of separate pixels at a variety of resolutions using a range of different technologies.

As a result, good typefaces can be expensive, especially if you want to adopt a font collection as a company standard for your corporate identity, and you want to license it correctly for all possible uses, including on the web, in print, for editorial, in advertising, on posters, in films and videos, for redistribution embedded in presentations and documents, and more.

“Free” font collections abound online, but – as with videos, music, games and other artistic content – many of these downloads may leave you with dubiously licensed or even outright pirated fonts installed on your computer or used in your work.

Nevertheless, many distinguished font creators provide open source fonts available for personal and commercial use, and numerous free-and-properly-licensed font collections do exist, including the well-known Google Fonts.

In fact, the Google Fonts site not only allows you to download font files to use in your own documents or to copy onto your own web servers to embed into your web pages…

…but also allows you to link back to a Google Font server so you don’t even need to host the file yourself.

For boutique websites, that’s convenient because it means you get font updates automatically, and you don’t have to pay any bandwidth fees to your hosting provider for sending the font file to every visitor.

Local or cloudy?

On the Naked Security website, for example, our body text [2022-01-31] is set in a typeface called Flama, which isn’t open source.

So, we host the font file ourselves and serve it up as part of the web page, from the same domain as the rest of the site, using an @font-face style setting, in the fashion you see here:

This means that even though you are unlikely to have Flama installed yourself, our website should render with it in your browser just as it does in ours, using the WOFF (Web Open Font Format) version of the font file.

The Flama WOFF font you see below is modestly sized at just 26KBytes, but is our responsibility to serve up as needed:

Licensing and serving in one place

So, Google Fonts not only “solves” your licensing issues by offering open source fonts that you are allowed to use commercially, it can also solve your “how to serve it” hassles, too.

You simply link to a Google-hosted web stylesheet (CSS) page that sets up the necessary @font-family specifications for you, and fetched the desired font files from the Google Fonts service, like this:

<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=fontyouwant">

Of course, that means that Google’s servers get a visit from your browser, and thus Google unavoidably gets your IP number (or an IP number provided by your ISP or VPN provider, which loosely amounts to the same thing).

If you have some sort of tracking protection turned on, your browser might not fetch the requested CSS and font data, in which case you’ll see the text in the closest available font your browser has available.

But if you haven’t set your browser to block these downloads, you’ll get the font and Google will get your IP number.

Is that private enough?

Apparently, not always.

A District Court in Munich, Germany, recently heard a legal complaint in which the plaintiff argued that a website that had linked across to Google Fonts, instead of downloading and hosting a copy of the free font on its own site, had violated their privacy.

The court agreed, demanded that the website operator start hosting fonts locally, and awarded the complainant damages of €100 (about $110).

The court’s argument doesn’t seem to be suggesting any and all other third party “widget linking” is now considered illegal in Germany (or, more particularly, in the region where this court holds sway), but only that websites are expected to host content locally if that’s easily possible:

Google Fonts kann durch die Beklagte auch genutzt werden, ohne dass beim Aufruf der Webseite eine Verbindung zu einem Google-Server hergestellt wird und eine Übertragung der IP-Adresse der Webseitennutzer an Google stattfindet.

(The defendant [i.e. the website operator] can make use of Google Fonts without establishing a connection to a Google server, and without the IP address of the website user being transmitted to Google.)

What next?

If you’ve ever had rogue adverts – what’s known as malvertising – thrust into your browser when you’ve visited an otherwise unexceptionable and trustworthy website, you might be thinking, “This is a great decision, because if everyone who monetised ads served them up from their own domains, it would be much easier to keep track of who was responsible for what, and ad filtering would become a whole lot simpler.”

But if you’ve ever visited boutique websites that have tried to do it all themselves and found yourself struggling with content such as JavaScript that could have been updated but hasn’t been, or server-side plugins that seem to contain bugs that you thought were fixed long ago, you might be thinking, “Sometimes, it’s worth having a web content supply chain that’s longer and more complex that is strictly necessary, if the content providers further up the chain have more knowledge and resources to keep things up to date.

There’s also the problem that this judgement has penalised a website provider for linking to a Google service that has (or at least claims to have) a pretty liberal privacy and tracking policy:

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.

Yet the judgement is of necessity mute about embedded links that track users as part of their service, such as web analytics tools, because those services are almost always cloud-based by design, and therefore cannot be hosted locally.

Are those to be made illegal in Bavaria, too? Or will the cloud-centric nature of web analytics effectively exempt analytics services from this sort of judgement simply because the expectation is that they’re rarely, if ever, hosted locally?

And what about so-called “live content” from other sites?

Twitter, for example, requires that if you want to show a complete tweet in your web page, you need to embed it directly, rather than locally hosting a screenshot and providing a link that a user can optionally click later on.

From a traffic point of view, that makes sense for Twitter, because “live” links not only display current tweet statistics, but also make it really easy for readers to engage frictionlessly with the tweet.

But it also makes sense from a legal and cybersecurity point of view, because Twitter itself can adapt data that’s embedded via links to its site (such as deleting offensive, illegal or misleading content as desired or required), instead of relying on every website that ever took a screenshot of a tweet to go back and update or remove the content if common sense or a court order demands it.

Have your say

Where do you stand on this?

Do you think this is an overreach by the court?

Do rulings like this suggest we’re heading towards the end of the era of third-party adverts (after all, adverts don’t have to be served via the cloud; they all could be served locally, even if most services don’t yet support that way of working, and even if it’s a lot less convenient)?

Will we be more secure if all website operators are required to self-host all content such as the stylesheets and JavaScript they rely upon, or would that inadvertently favour the crooks by leaving us with more out-of-date code than we would otherwise have?

Let us know below… you many remain anonymous if you like.

---