The web has a long and storied history with text, typography and fonts. Most content on the web is text. And at the very least, typography accounts for 95% of web design.
In the early days of web development (circa 1997), web design was limited to fonts that were available with the operating system, be that Windows, MacOS, or Linux. Couple that with limited crossover of font options between the operating systems, and most of the time, this resulted in all websites using four fonts: Arial, Helvetica, Verdana, and Times New Roman.
So, historically, the year is 1997 and Microsoft releases Internet Explorer 4. Along with it, the first means for downloading custom fonts in a browser. Among these were Microsoft’s Core Fonts for Web, a set of typefaces made freely available for web design. This pack included widely used system fonts like Times New Roman, Arial, Comic Sans, and Trebuchet. Alternatively, designers could use font families such as Serif, Sans-Serif, and Monospace to specify the general style of a font even if a specific one wasn’t available.
And the problem? A lack of industry standardisation resulted in near zero support from other browsers.
Whilst Internet Explorer 4 was the first browser to adopt custom fonts, it would be a long wait until 2011 where support for custom fonts was supported across the big four browsers; Internet Explorer, Chrome, Safari and Firefox.
So, from 1997, widespread support for custom web fonts brought creative options that were simply not possible before in web development. From matching a brand’s font, to flourishes designed to entice and create interest, the options were endless. Whilst the benefits of custom fonts are evident to most, what wasn’t evident, measured, nor understood (for quite some time), were the impacts to UX, performance, and the environment.
How could using fonts via Google’s service possibly run afoul of GDPR? The fact of the matter is that, when a font is requested by the user’s browser, their IP is logged by Google and used for analytics.
Lifehacker
Web fonts come at a performance cost
The problem, though, was fonts could be quite large assets, some being several hundred kilobytes (this is still true today). Over the years, due to poor user experiences (caused by slow load times, or sometimes not loading at all), font loading strategies were developed to address these symptoms.
Custom web fonts are an essential part of most web design, but they come at a performance cost. As the speed of internet connections improved, less focus was placed upon optimising the amount of information transferred, and whilst that was shortsighted, it simply reflected the attitude of the time.
Did you know that your web browser is automatically downloading and using fonts that aren’t installed on your system?
Web Fonts
In 2009, the WOFF font format was developed, and subsequently sent to the W3C to become part of an open standard. The release of the WOFF format signaled a new day for web fonts, and implementation reached more or less a consensus among browser makers and developers. Here’s the tricky bit. Web fonts had been technically feasible and ready to go since 1998, with the release of Internet Explorer 4.
The First Font Rules
The creators of the web understood the importance of typography and font selection in the early days. Back then, the web was more or less just text. So even the first version of CSS in 1997 made special mention of fonts. The specification contained the first ever font styling rules, which included font-family, font-variant and font-weight. As browsers moved to implement these font rules, designers began to have some actual (but still fairly basic) control over typography.
There was one catch. For a user to actually see a developers font choice with font-family on a web-page, the font itself needed to be installed on their computer. But the web was multi-platform (a feature, not a bug I might add), so browsers could be used across computers and operating systems. Because operating systems were so different, there were very few guaranteed choices.
Microsoft helped quite a bit when they commissioned and then released for free two fonts designed specifically for the web, Verdana and Georgia.
Introducting @font-face
To solve this problem a brand new rule was introduced in CSS2, which started to make the rounds in 1998. It was called @font-face and it let developers link to a URL of a font file that browsers could download, and then display on a webpage. So even if the user browsing a page did not have a font installed on their computer, they could still view it.
Internet Explorer, a bit ahead of the curve at the time in terms of CSS support, was the first to implement @font-face. Netscape wasn’t far behind. And suddenly, designers could use custom fonts.
At least, in theory.
It turns out, the biggest issues standing in the way of web fonts were not technical. They were legal.
The History of The Web
The Problem with Web Fonts
The @font-face rule allowed developers to pass just about any URL to the src attribute. But passing a URL to a downloadable font there, meant that it was easily accessible for any user to download and install anywhere. So if I embedded a font on my own site, another user could download the font and use it on their own site, or let’s say commercial software, without ever paying for a license.
The opinion on this particular matter was a bit split among font creators. Some believed that this was just the way of the future, and that enough legitimate users would pay for licenses in the long run.
How Web Fonts Work?
The biggest Web Font provider, Google Fonts, is an expansive web library of over a thousand fonts. You can use them on your website by pulling them via CSS, and mobile developers can access these fonts when creating Android apps.
When a web page uses Google Fonts, it pulls a font from Google’s database and then displays the text in that font to you in your browser. These fonts are hosted on Google’s server and are loaded nearly instantaneously. Other cloud font services work much the same way.
The Google Fonts repository and all the fonts under it are entirely free to use and accessible to everyone. It only uses fonts under an open license, and many of these fonts have become staples of web design, like Roboto, Lato, and Montserrat. Google hosts a website that lists all of its available fonts and allows you to try them out and compare them with each other. Google also offers a database of free vector icons.
Another alternative is using self-hosted, embedded fonts on the web instead. This is done through the Web Open Font Format (WOFF)—a compressed font file developed by Mozilla that’s compatible with most modern web browsers. WOFF is useful if you want to embed a custom font that isn’t available on a web font service.
WOFF
By 2011, this format would be introduced in every major browser bringing with it true cross-browser compatibility and font creators from around the world began making their fonts available. The Web Open Font Format (WOFF) was officially released. It’s creation represented the combined efforts of Microsoft, Opera, Mozilla and several type designers and font foundries. It kept font files lightweight, and encoded files for web use only (to help with licensing). Finally, a font had arrived that everyone could agree on.
With greater choice came greater innovations. Designers began experimenting, and once again typography was brought to the forefront of design. But as with just about any decision the web, there was a lot of work behind the scenes to make it happen.
How the Internet Works?
When you visit a website, you’re in reality requesting a document, which is served to you by the server. This request is done through a URL, which looks like this:
[protocol] :// [pretty-name-pointing-to-a-server-IP-address] . [tld] / [path] / [to] / [document]
I’m sure a real world example will seem more familiar to you:
https :// thelematics . com / latest / web-fonts-use
Basically, by requesting the above address, you’re telling the server: Hi server! I just requested files from thelematics.com via a secure connection (https). I would like to view the document named ‘web-fonts-use‘ in a folder named ‘latest‘.
Example: Burgers & Fries
Let’s compare the internet to a restaurant. A very modern, and ultra cool restaurant where orders are placed directly on your table, without any intervention of a waiter/waitress.
Your friend orders a burger with a side of fries, but you’re counting calories, so you’ll only take a salad and a XXL Banana/Oreo Milkshake.
For the waiter to know where to serve your food, it is required to provide your table number with each order. Makes sense, right?
Now, to complete this puzzle:
- Table number = Computer’s IP address,
- Waiters = Servers (because well, they serve. Duh…),
- Order = Request,
- Food = Document,
- And your friend — well, I hope she’s still your friend.
Now let’s rewrite that last sentence:
For the server to know where to serve your document, it is required to provide your IP address with each request. Makes sense, right?
Now, let’s circle back to Google Fonts.
GDPR and Google Fonts
Essentially, there’s nothing wrong with this way of working, until external requests come in to play.
A document can, in itself, request other resources, e.g. images and — drumroll, please! — Google Fonts, which are located on another server.
Let’s imagine that your friend’s fries come with complementary packets of mayonaise and ketchup handmade by another ultra modern restaurant across the street — conveniently named ‘Le Góog’.
In order for the waiter across the street to know where to serve the packets, your table number is sent to Le Góog directly after placing your order.
If you weren’t paying attention: this means that your IP address is (instantly) shared with Google’s servers, while you thought you were just sharing it with a — very trustworthy and passionate — hamster hobbyist.
To clarify, GDPR states that all personally identifiable information is forbidden to be shared without a user’s explicit permission, i.e. a cookie notice. An IP address is just that: personally identifiable information.
What Google’s doing About it?
“Luckily” Google has put “a lot” of time and “effort” in “reassuring” us that they’re not planning to do anything with our data.
The Google Fonts API is designed to limit the collection, storage, and use of end-user data to what is needed to serve fonts efficiently. […] Google Fonts logs records of the CSS and the font file requests, and access to this data is kept secure.
Google Fonts FAQ
A beautiful statement containing some difficult, yet comforting words, leaving you somewhat reassured and — totally paranoid.
In other words: they’re not doing anything about it.
To be fair, they can’t not receive the IP address, because that’s how the internet works. But the least they could do is offer some reassurance that they’re not using it for anything else. Instead they say they do log it, but in a very very very safe place.
Which Google (or other) Fonts is my website using?
You’ll be happy to know that figuring out which fonts your website is using is really easy. Every browser has a built-in interface to show you all sorts of information about the webpage you’re viewing, called Developer Tools. Check it out!
Help me fix this, please?
Essentially, the only way to prevent your IP address from being sent to Google, is by not requesting fonts — from the Google Fonts API — at all.
But that doesn’t mean you can’t use Google Fonts anymore.
A proposed solution is to host your Google Fonts locally. The solution to make Google Fonts comply with GDPR lies in hosting Google Fonts locally.