FontEnigma

LeMo aka PatternMan aka Frank E Blokland

A lot of type-foundry websites use retail fonts to display and demonstrate the qualities of typefaces. The inevitable risk is that font data becomes easily accessible for downloading. This is sometimes countered by the argument that professional graphic designers and companies will buy a license anyway. However, that in turn is somewhat contradicted by the services that crawl websites specifically to detect unlicensed use of fonts. In general, professionals avoid unauthorized fonts, but unfortunately, font data can sometimes end up being shared online (possibly by mistake) without clear authorization.

In a dispute with a graphic-design agency that had used DTL fonts without a license a few years ago, the agency’s owner argued that we, as producers, should prevent our fonts from being so easy to copy and distribute. I replied that leaving the windows of my house open is not meant as a generous invitation to burglary. Of course, I can close and lock the windows, but I cannot build something into the font data itself that prevents copying.

What I can do, however, is choose how the fonts are displayed online. For example, one way is to serve text as images, as we do on this website, which uses the somewhat vintage TypeShow software. In this case, the fonts themselves are never exposed to website visitors. Still, one could argue that serving fonts directly is faster and offers better performance, dynamic layout control, and accessibility. If we choose to serve fonts directly, there are, however, still ways to make unauthorized downloading less appealing:

      – character-set reduction
      – contour-quality lowering
      – font-encoding obfuscation
      – font-layout scrambling

The first two methods are standard in DTL’s web fonts. The character set is somewhat reduced, which also decreases the GPOS and GSUB features (these are subsetted during font generation). In our webfonts, the conversion from cubic to quadratic splines is performed more loosely. This reduction in precision is not visible on-screen, even when zoomed in. However, it not only makes the webfonts smaller, but also different from the retail desktop fonts and less attractive to use outside of websites. Of course, other techniques can also help distinguish web fonts from desktop fonts. Our desktop versions are typically OpenType CFF fonts (except when the client wants the TTF version). Another benefit of these modifications is that they reduce file size, for example, by minimizing name-table entries and removing redundant cmaps, where applicable.

Encoding obfuscation is particularly effective when one controls the environment in which the fonts are displayed. The rendered text can be decoupled from standard Unicode code points, allowing for a scrambled encoding. The text typed by the user (scrambled by reassigning standard Unicode code points to different glyphs) is displayed correctly via translation in the controlled environment. If this text is copied into another program, it appears garbled, making the font practically unusable.

Scrambling the font layout is of secondary importance, but it makes it a bit harder to extract and reuse glyphs. By distributing glyphs randomly like confetti in a sea of empty character slots, copying becomes less attractive and the font file somewhat bulkier than necessary.

To explore these possibilities in practice (and because I found it an interesting challenge), I have made a beta version of an obfuscation environment, called ‘FontEnigma’, which can be tested here. FontEnigma also supports variable fonts: if such fonts are detected, sliders will appear automatically. These sliders are currently predefined, but could eventually be generated dynamically based on the font data. There are some rough edges in the environment still: for example, when using modifier diacritics or toggling kerning on and off multiple times. However, overall, this beta version of FontEnigma correctly displays an obfuscated version of Stijn Cremer’s DTL Estuary.

A key is used to map scrambled Unicode code points back to readable text. I am fairly confident that many participants on TypeDrawers could crack this key, as it is not exactly rocket science. Nonetheless, if you do manage to break it, please do not post it publicly. Making it easier for third parties to reverse-engineer the fonts would defeat the purpose, though doing so would still require a fair amount of effort and skill. That said, I can always update the obfuscation method and the decoding key if needed.

Speaking of keys, the key question is whether it makes commercial sense to generate modified font versions specifically for demonstration purposes. Is the extra effort justified? I believe it is. Protecting your licensees is essential: after all, they have paid for the right to use your fonts. In DTL’s case, implementing the kinds of modifications described above is relatively straightforward and can be largely automated. I reckon that is true for many other workflows as well, regardless of the file formats involved. This summer, I plan to work on ironing out the remaining glitches: it will undoubtedly be fun. If you are interested, I will be happy to share updates as progress continues.

As a side note, the idea of font obfuscation for the web is not entirely new. For example, at the ATypI 2011 conference in Reykjavik, Jürgen discussed font scrambling and HTML re-encoding for web-embedded fonts. There may well have been other similar experiments that I missed.

Peter Constable

FontEnigma makes the font data less appealing by making the font non-interoperable by using a custom encoding. The corollary is that it also makes the text non-interoperable. One implication is that a Web site will not work with accessibility tools such as screen readers, meaning it will not be compliant with WCAG or with the EU Accessibility Act, which goes into enforcement next month.

LeMo aka PatternMan aka Frank E Blokland

Hi Peter, it is perhaps fair to say that this tool might fall outside the scope of the EU Accessibility Act and WCAG requirements. After all, it does not provide any authored or published content as it just takes whatever the user types in and renders it for visual font testing. The obfuscation of Unicode is there purely to protect the font from being used in an unauthorized way, and it does not block any interaction or hide information from users with disabilities.

Since the tool is aimed at developers and not the general public, and it does not contain any built-in content, the usual rules about making information perceivable and understandable may not really apply here. That said, I am not a legal expert and this is just my interpretation of how things might reasonably be viewed.

John Hudson

From your original post, Frank, it wasn’t clear if you were talking only about type testers or foundry web page content in general.

If a foundry is selling webfont use licenses to customers, as is the case for most foundries today, there seems little point in trying to obfuscate the fonts on the foundry site. As soon as the fonts are in use in the wild, they are vulnerable.

I replied that leaving the windows of my house open is not meant as a generous invitation to burglary.

This is similar to the metaphor which inspired the WOFF format: there is a difference between picking up a wallet lying on the ground beside a car and picking up a wallet from inside the car, even if the car window is open.

LeMo aka PatternMan aka Frank E Blokland

Hi John, my main point is that at least DTL should not make it easy for fonts to be copied or shared without our permission. We cannot stop everything, but obfuscation and subsetting are not hard to do anyway and and doing this shows our paying customers we are protecting their investments the best we can. After all, our niche market is based on exclusivity, and unauthorized distribution does not help.

LeMo aka PatternMan aka Frank E Blokland

In addition, for the main copy on a website, I would never obfuscate the fonts: that would likely hurt SEO quite a bit. On the DTL sites, we use for this (relatively small subsets of) fonts, which, as mentioned above, differ from the retail desktop versions.