FontEnigma

LeMo aka PatternMan aka Frank E Blokland · May 31

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.

Quadratic Bzier curves with different resolutions

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.

Font-layout scrambling in DTL FoundryMaster

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 · May 31

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 · May 31

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 · May 31

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 · May 31

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 · May 31

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.

Alipey · June 2

Hi Frank,

Well, I thought you meant something a bit more sophisticated by “key.” At least a little.
Finding it honestly didn’t require "a fair amount of effort and skill"! It took just a few seconds.

please do not post it publicly.

I won’t post the key, but I think sharing this image should be fine:

(If you think it should be removed, let me know and I’ll edit the comment.)

I’m honestly surprised that you limited letter glyphs obfuscation to just letters? Numbers to numbers? Others?
Why restrict yourself like that? You could have replaced glyph outlines with anything.

Some suggestions:

Do the obfuscation using a key with no pattern and truly random numbers. For example, if we want to obfuscate 100 real glyphs, you’ll need 100 unique key pairs mapping the character Unicode glyph to character outline glyph:

1 - 36
2 - 89
3 - 12
...
100 - 61

(If you want to automate this flawlessly and quickly—just ask AI to do it.)
Even then, it’s still not that hard to find the key, because the outlines can still be manually matched to Unicode. That’s exactly how I figured out the real Unicode for ! and ?.
It might take a few days to do this for all glyphs manually. But with AI contour recognition? A few minutes, max.

The hardest thing for me to find was the space glyph! Because the font includes a massive amount of empty glyphs, and I couldn’t distinguish them from one another.
And that’s actually a good point:
Out of 5,584 glyphs in this font, 4,614 are fake — empty, same-width (and currently useless).
What you should do instead is delete these fake glyphs, then for each of the 970 real glyphs, generate 5 fully similar composite glyphs (it would be 4,850 glyphs at all).
Then randomly spread them among the glyph set, so that finding the key becomes many times harder.

Overall, I think this is a really good idea — especially the isolated web interface that prevents copying real Unicode of displayed characters. Keep going!

R ivzoob orpvw UlmgVmvtnz{

Dave Crossland · June 2

At least its not ROT13 lol

Peter Constable · June 3

An LLM likely can decipher the simple cipher. That means that an AI that can process font data likely could decipher the font data.

LeMo aka PatternMan aka Frank E Blokland · June 3

Hi Alipey, thank you for your efforts, comments, and advice: I really appreciate it. I am not surprised that you managed to crack the code easily. Dropping the invoked (obfuscated) JavaScript into Chattie would have done the trick too, as I tested early on. And yes, if you type the alphabet in one direction, the obfusction in the opposite direction will become clear when you copy the result into a text editor. Evib~dvoo~hklggvw}

Still, even this simple form of obfuscation serves its main purpose: making the fonts less attractive for casual downloading. If someone really wants to use them, they will need to put in some effort to get them working. Of course, it is possible to automate the Unicode reconversion. I am not sure the average downloader or crawler would go that far. And even if they do, what they end up with will still be inferior to the standard retail font data.

As for the complexity of the obfuscation: the principle appears to work well, and it should be possible to make it more sophisticated. I am sure, however, that AI will crack that code too in less than a jiffy. That said, I believe this light barrier is already sufficient to deter unauthorized distribution of fonts via a test environment (even before a single licensed copy has been sold).

Ultimately, it is about us (I can only speak on behalf of DTL) wanting to protect our customers’ investments as best as possible. And this may help a little.

Simon Cozens · June 3

LeMo aka PatternMan aka Frank E Blokland said:

Still, even this simple form of obfuscation serves its main purpose: making the fonts less attractive for casual downloading.

It serves its purpose! It works!

the principle appears to work well

It appears to work.

I believe this light barrier is already sufficient

I believe it works.

And this may help a little.

It may work.

Security systems can make us feel better, but whether or not they actually work needs to be back up by evidence, not by feelings. I don't say that in a mean way. Especially when it comes to computer security, where nothing is physical, it's much harder to tell the difference between bolting a door and uttering a magic spell. Either can make us feel protected. We only find out which one actually does protect us when someone barges the door down.

Alipey · June 3

You're right.
I agree that this is more than sufficient for the end user.

I think 90% of those who download the font from the font tester lose interest in continuing their adventure once they encounter the observation.

I think this is the best option for a type tester at the moment, although I do have better ideas in mind, I just need to think them through more.

John Hudson · June 3

This got me thinking about obfuscating font encoding while preserving text encoding. My idea is something like an Enigma machine in a layer between the text and the font, so the text—which is clean Unicode encoding, searchable, copyable, interchangeable—gets encrypted before it is displayed, and what is made visible is the encryped font encoding, which in theory could change every time the page is reloaded.

This implies a whole infrastructure between the text and the glyphs, but there’s nothing but convenience and habit that says the path between text and glyphs needs to be direct.

[I am not suggesting this as something I am interested in building, or that I think is worth investing in, only as the way I would approach this if I were to. Alternatively, one could sacrifice a goat.]

FontEnigma

Comments

Categories