Webfont Obfuscation: An interim solution?

paul.irish's picture

While we are waiting for WOFF support broadly, there are some protective measures available for webfonts to prevent them from being installed locally.

There is a technique of obfuscating the name table, rendering it unusable as a system font, but fully functional as a webfont. Ethan Dunham of Font Squirrel and Fontspring has led much of the research below, based on some prior work from Peter Bilak of Typotheque and Philip Taylor with his Font Optimizer [0]

Specifically, these are the modifications for a TrueType font:

  • Delete all name entries except for platformID 3, platEncID 1, LangID 0x0409
  • Set entry 1 (Font Family) to '' (empty string)
  • Set entry 2 (Font Subfamily) to a unicode smiley:☺ [1]
  • Set entry 3 (Unique ID) to '' (empty string)
  • Set entry 4 (Full name) to smiley:☺
  • Entry 5 (Version) may optionally be changed. Ethan recommends inserting some verbage about the font being protected. It shows up in the get info window on Mac
  • Set entry 6 (Postscript name) to smiley:☺
  • Entries 7-14 can remain as is
  • Delete entries 15+

Create two Mac entries: platformID 1, platEncID 0, LangID 0x0

  • Set entry 1 to blank (basically have an entry but no value)
  • Set entry 4 to the Font Name (optional but will show up in Get Info)

When the Font Family name is an empty string, it is uninstallable in Windows. Meanwhile, the OpenType spec indicates that two-byte unicode characters (like the smiley) won't work in a font name on Mac at all. [2] As a result, it's rejected by OS X and not possible to install. Linux isn't able to cope with these modifications either. [3]

These changes are done not only to the TrueType "naked" font, but can also be applied to the underlying TTF embedded in the EOT and WOFF files as well. It's also worth noting that Chrome's font sanitizing library OTS completely avoids the name table. [4]

I believe all non-free fonts should employ these changes as they are distributed for web use, essentially providing them with a similar "garden fence"-level of protection [5] as WOFF. Fontspring is already employing this technique, and you can test it out with the WebOnly option at the Font Squirrel generator [6].

If you guys think this is worthwhile, I'd love to help draft this up into something more official so it's a documented standard that all foundries can use when preparing their work for sale as a webfont.

[0] http://bitbucket.org/philip/font-optimizer/src/tip/obfuscate-font.pl
[1] http://www.fileformat.info/info/unicode/char/263a/index.htm
[2] http://www.adobe.com/devnet/opentype/afdko/topic_feature_file_syntax.html#9.e
[3] http://paulirish.com/i/LinuxWebfont.png
[4] http://code.google.com/p/ots/source/browse/trunk/src/name.cc#23
[5] http://lists.w3.org/Archives/Public/www-font/2010AprJun/0061.html
[6] http://www.fontsquirrel.com/fontface/generator

Edit: Clarified the Windows installability reason. Worth noting: when the full name doesn't match Font Family + subfamily, it is uninstallable in Windows, however they match with this above technique, which is why the EOTs with this modification still work. (thx Ethan)

fontsquirrel's picture

Like Paul said, you can already do this with the Generator by selecting the "WebOnly" Option. I'm interested to hear your thoughts on it all. A more robust foundry service is in the works.

gryzzly's picture

Whoa, finally something on the subject.

I've posted a question on the css-design google group, but, clearly, that was a wrong place to ask such a question (no replies).
http://groups.google.com/group/css-design/browse_thread/thread/d3ccff333...

Thank you guys.

So, all the mentioned stuff is already being done if I use "WebOnly" from the Fontsquirell?

Ethan, Paul, you rock.

elliotjaystocks's picture

Thanks for doing the research, guys. This is one to save, keep, and refer back to constantly.

Top work!

fontsquirrel's picture

@Misha - Yes, all this is already being done in the generator.

@Elliot - Thanks!

One clarification to Paul's documentation: It is uninstallable on Windows not because the names don't match (they do and that is why the EOT works), but because the Family Name is .

Si_Daniels's picture

I think the problem with solutions like this is that a browser or OS would be well within its rights to reject such a font. We've seen security fixes for font-based attacks from Mozilla and Apple in recent months. As part of the hardening of apps and OS's against attack, support for hack fonts may disappear in an instant - through a security fix or browser update. That's probably okay for a service like Typekit that can react instantly, but for someone hosting their own EOTs or raw fonts that would appear to be a problem.

fontsquirrel's picture

@Simon - Agreed, it is a potential issue. But can you see any reason why they would suddenly start paying attention to the table if they aren't already?

paul.irish's picture

@sii, Yeah, totally a legitimate concern. I've asked a friend who works on the Chrome team that developed OTS (arguably the most aggressive in-browser font security software) to look this over. My expectation is he'll give the thumbs up, but like you, I want to feel confident about it.

Since OTS was started, it has had this comment in the source, which puts me at ease:
// NAME is a required table, but we don't want anything to do with it. Thus,
// we don't bother parsing it and we just serialise an empty name table.

I'll also try to bounce this off John Daggett and Jonathan Kew of Mozilla. If you have contact with any webfonts engineers with IE, I'd love their input

Si_Daniels's picture

>would suddenly start paying attention to the table if they aren't already?

If a documented exploit involved malformed name table entries, they may verify all entries not just the one associated with the exploit.

>If you have contact with any webfonts engineers with IE, I'd love their input

For sure, I'll point them at this thread.

Cheers, Si

Thomas Phinney's picture

I'm curious what other browsers may have been tested besides IE, Firefox and Chrome. How about Opera? Anything else? Any obscure browsers known to NOT work?

Cheers,

T

fontsquirrel's picture

Yes, Opera Mac works fine. And I don't care honestly about obscure browsers. What is the Extensis strategy for protecting fonts?

paul.irish's picture

> How about Opera? Anything else? Any obscure browsers known to NOT work?

Opera Windows and Opera Mac work with these files.

Camino doesn't yet support @font-face but since they lean heavily on Gecko, it's safe to say the experience will match Firefox.

I don't believe Epiphany or Konqueror either support @font-face yet (or really any of CSS3).

Si_Daniels's picture

I heard back from one of the lead font engineers. He agreed with my assessment, but declined to speculate on the likelihood of Windows or IE changing their behavior.

Thomas Phinney's picture

Ethan (fontsquirrel) asked: What is the Extensis strategy for protecting fonts?

In the current "technology preview" of our service, we do a bunch of measures at different levels, including a number of things relating to font processing, along these general lines.

That being said, there's no question that this level of font crippling is more extensive than what we're currently doing. It's something we'll be looking at carefully.

Cheers,

T

Richard Fink's picture

@paul and all:

As you probably know, Ethan and I have discussed this a bit.
And as TP will attest, I was on a quest for the "uninstallable font name" months ago (because of the local() problem) but you and Ethan beat me to it and I appreciate and salute the hack.

My initial reaction was like Sii's - a general nervousness. There's something about it that seems frail, easily broken.

However, after mulling, the bottom line is: if the naming scheme is legit as far as the OT spec is concerned, there is no reason that I can see that it is any more vulnerable - security wise - than any other combination of entries in the name table.

(And remember, no security guy is ever, ever going to tell you that something is 100% rock solid safe. If we could predict what an attacker might come up with, there would be no ongoing need for security guys. The question is: is this less safe than any other set of naming entries? Not that I can see.)

Which leads me to a whole other line of inquiry...

All along, it has been assumed that the font delivered to the browser is easily installable in the OS. It's fair to say that this is what bothered commercial font vendors the most.
However, you've shown that's not true. The uninstallable font already exists, de facto, you've found it. And all it requires is some particular comination of entries in the name table.

All along, the focus has been on what browsers are going to to do with a font that was assumed to be installable when the real problem has always been what the OS was going to do if the user, let's say, extracted it out of the cache and tried to install it.
Success at that has always been assumed.

With all the brouhaha going on at the W3C working group over embedding bits and mandates about what browsers and WOFF conversion tools SHALL or MUST do, my question is, why not codify something like this? It already exists.

What would be objectionable about a naming scheme that makes the font uninstallable by asking that the underlying OS should, pretty please, not install a font so named?

I can't see the major players like MSFT or Apple objecting to this.

I mean, this issue was the prime impetus behind EOT and, ultimately, WOFF so why not tackle it from this angle, as well?

I dunno, just tossing out the idea. Worth thinking through, I think.

Rich

John Hudson's picture

Rich: if the naming scheme is legit as far as the OT spec is concerned

There's the rub, I think. The proposed modifications of the name table are not really legit as far as the OT spec is concerned, at least as interpreted by the OS makers, which is precisely why the system will not install such fonts. This method of obfuscation is based on a current difference between the handling of web fonts and the installation of fonts on the system, and I don't see any grounds for either presuming that this difference will be maintained in its present state or that such a difference can be formalised.

Tim Ahrens's picture

Thanks for the summary, Paul!

Non-complicance concerns aside, would it be worth trying to corrupt the font file even further so that it can't be fixed with a font editor?
I played around a bit and managed to create a TTF that works as a web font in Safari but crashes FontLab when you try to open it; TTX doesn't work either but FontForge can open it. The problem is that it doesn't work in Chrome. It's just a quick attempt – maybe a TrueType file format wiz could devise something that works in browsers but can't be opened in editors?

Tomi from Suomi's picture

Is there a way to make this more complicated, or are we now in a plateu-face looking at possible standards?

fontsquirrel's picture

@Tim- Chrome is the kicker because they are using a library to "qualify" a font. It must pass a myriad tests before it is considered safe. Obviously whatever you did raised a red flag. That is why the NAME table at this point is where our energy is focused.

@Tomi- Ideally yes, but it is all undiscovered and untested. Likely there are few to none other alternatives right now. A font still has to behave like a font after all.

Richard Fink's picture

@jh

This method of obfuscation is based on a current difference between the handling of web fonts and the installation of fonts on the system, and I don't see any grounds for either presuming that this difference will be maintained in its present state or that such a difference can be formalised.

Yes, it exploits a "blind spot" in the way Windows and OSX currently recognize a font.
And there is no way to know if the blind spot will stay blind unless MSFT and Apple say it will.

But going forward, how about a simple naming convention that signals to the OS that the font should not be installed?
Be aware that commercial font producers and web designers may soon have a very common interest here.
If I break my little tush re-hinting a font, playing with the outlines, converting it, and subsetting it a certain way, I might very well want to sell the thing and not want it easily installable either.

With the acquiescence of only two parties: MSFT and Apple, things can be made simple. And I can't see what beef anybody would or could have. Forget embedding bits and EPAR tables and all that sh-t. Why couldn't a simple naming convention be adopted that asks the OS not to install the font? Making it Browser Cache-Only.
I mean, why not? Too simple?
Not much of a garden fence, but about as good as WOFF. And the two together would be about all you could hope for.

And since the internal name of the font is really irrelevant to @font-face, why not just decide on an internal keyword name that requests this non-installable treatment?
There is precedence for it with the keyword font names in the CSS 2.1 draft, too.
(cursive, serif, sans-serif, monospace - how about adding 'cache' to the list and asking user-agents to check for a match in the font's internal data and ask the platform providers to respect it?

Sii, is this nuts?

Just thinking out loud...

(Have to figure out how to get backward-compatibility, though. Can Ethan's hack be merged with such a thing? Probably.)

Rich

Si_Daniels's picture

I doubt clients or OS’s would respect an unofficial keyword, not part of the OpenType standard. However, if the OpenType spec were rev'd to include a "do not install" bit, then I would expect that clients and OS’s would support it.

I think there would likely be push-back on standardization of such a bit. WOFF is already a “do not install” format, and depending on how clients temporarily install linked or embedded fonts they may run afoul of OS-level checks causing app compat issues. Add to this the ease of flipping the bit, it would seem to be a lot of work for little reward.

I think a more promising approach, one more likely to succeed, would be a fully spec’d permissions/electronic EULA table, where “do not install” is just one of several properties exposed.

Rob O. Font's picture

>Why couldn't a simple naming convention be adopted that asks the OS not to install the font?

Lol.

Richard Fink's picture

I think a more promising approach, one more likely to succeed, would be a fully spec’d permissions/electronic EULA table, where “do not install” is just one of several properties exposed.

Promising in a way, perhaps, but I have problems with what it promises.
I'd rather it remain as is than go down that road.

Rich

paul.irish's picture

> I don't see any grounds for either presuming that this difference will be maintained in its present state or that such a difference can be formalised.

Why not?

Here's a slice of the browsers in use and their marketshare:
EOT (IE 6-8): 52.7%
WOFF (FF3.5+, Chrome6): 20.8%
TTF/OTF (FF<3.5, Chrome<6, Opera): 25.4%
SVG or no support: 1.1%

So there is still a good 25% of users completely unserved by a EOT/WOFF license like FontShop's.

We still don't know for sure about Apple's plans to support WOFF. Last I heard, their lead engineer said it's easier for them to make WOFF an installable format, so that hardly solves the problem.

But now we have a format, which has protection on the level of WOFF (and even better in some cases), and works in all browsers *today*. Simon, John, David: that doesn't interest you?

Si_Daniels's picture

>But now we have a format, which has protection on the level of WOFF (and even better in some cases),

I wouldn't describe what you've outlined as a "format", rather a set of obfuscation techniques. I find them interesting, but not that surprising - obfuscation is generally required by any font-maker considering font linking and embedding schemes, and the services (like Ascender's and Typekit) include obfuscation.

>works in all browsers *today*.

My only point was that they may not work tomorrow. In which case they'll evolve, or die.

>their lead engineer said it's easier for them to make WOFF an installable format

I think it’s up to the W3C working group to ensure that compliant apps and clients do not treat WOFF as an installable font format.

Read Roberts's picture

One issue with putting garbage data in a font is that it is hard to predict all the workflows which it might affect. Have you tested printing to PostScript and non-PostScript printers, and to PDF?

Richard Fink's picture

@davidberlow

>lol

Just a bit of giveback for all the amusement you've provided me!

(Hey, will you be at Extensis' shindig in Boston this weekend?)

rich

Rob O. Font's picture

PI>David: that doesn't interest you?

Yes Paul it does. Thank you for the interesting material. We have adopted much like what you describe in some of our web font obfuscation technology to serve dressed naked fonts.

I'm always a bit leery about doing any messing with the font names because they are so fragile to the user, and I can't help imagining that useful file and font names with meta data support is a good goal to seek for users now.

One of the classic issues we've been facing (all composers and users of digital type), for the last 30 years, is how to keep track of fonts, (from conception to uses), mostly by file name and font name. So, e.g. for years we've been shoehorning size and foundry info into names along with family, repertoire and style info.

As I understand it, I could have to ship fonts like: FBSavageGothicBoldCondensedItalicDisplayProWebForIPadSVG18PTnot4woff.svg, and the file name could be SHTHD211.

Sii>My only point was that they may not work tomorrow. In which case they'll evolve, or die.

Simon's point is well taken, but all obfuscation techniques must evolve or die of pressure from other, arguably, overriding forces as well. The point is, however, it is the combination of obfuscation and meta data, one for the garden and one for the court, that protect fonts from most manner of ill gotten gain. It is not the font format.

Cheers!

paul.irish's picture

Sii>My only point was that they may not work tomorrow. In which case they'll evolve, or die.

Sure. Though being future-proof isn't really a goal of this project. It looks pretty certain we'll have WOFF support across all browsers within 9 months.

This is stated as an interim solution, as I'd think foundries would be interested in licensing their fonts to work, securely, in 100% of supporting browsers today. :)

henrypijames's picture

I'm absolutely astonished that all discussions so far are concentrated on the feasibility of this hack and nobody is making the principled argument that intentional poisoning of standard data formats is unconditionally evil, and security by obscurity really never works -- especially when the structure of the underlying format is public knowledge.

Since any software that encounters the intentionally crippled data may behave in unpredictable ways and thus open up vectors for attack, this kinds of hack -- in an environment as fragile as the web no less -- puts the data integrity and system security of the user in great danger and is therefore utterly irresponsible. As an user, I would consider this kind of technique a willful act of intrusion and endangerment -- much like rootkit DRM -- and say to anyone who employs it: Go to hell!

Some -- actually, many, as it seems -- people here need a computer security 101 lecture: The integrity of data exchanged in an open environment has -- by magnitude -- higher priority than a little bit more visual enhancement for your website.

Si_Daniels's picture

>intentional poisoning of standard data formats is unconditionally evil

Christopher Slye's picture

One issue with putting garbage data in a font is that it is hard to predict all the workflows which it might affect. Have you tested printing to PostScript and non-PostScript printers, and to PDF?

Still interested in an answer to Read's question.

blank's picture

I'm absolutely astonished that all discussions so far are concentrated on the feasibility of this hack and nobody is making the principled argument that intentional poisoning of standard data formats is unconditionally evil, and security by obscurity really never works -- especially when the structure of the underlying format is public knowledge.

You have to remember that this entire discussion is pretty much based on an inane fantasy in which intentional piracy is inevitable but users unintentionally pirate fonts by downloading web fonts and installing them without realizing that the a font license should be paid for somewhere along the way. So you really shouldn’t be surprised that the methods for preventing such a scenario are equally ridiculous.

fontsquirrel's picture

James - Not sure I understand the tone of your post. What would you suggest? Typekit obfuscates, Fontspring obfuscates, Extensis, Ascender, Typotheque etc... To serve fonts on the web at this point has to involve a certain level of trust. None of the schemes offered by these services is unbreakable. I've easily downloaded fonts from all of the them. But if I was a "casual pirate" without the font tools, I would stumble here. Would you be comfortable with your naked fonts on the web?

henrypijames's picture

I suggest you stop messing with the standard formats and keep waiting for a standard-conform web font technology that you like. Not having web fonts is not a big deal -- having intentionally corrupted data is a huge deal.

And yes, as an developer of several open source projects, I have absolutely no problem whatsoever giving away my work for free. But that's beyond the point.

blank's picture

I am just continually confounded at how much thought and effort goes into trying to protect web fonts from being used as system fonts given that casual pirates will probably always take the casual route and just google “fontname font rapidshare OR torrent”. I don’t entirely love the idea of naked fonts on the web. But I don’t see a need for all these hacks because I think it silly to believe that anyone who will to make the effort to pirate web fonts would pay for fonts to begin with.

Rob O. Font's picture

henrypijames >I suggest you stop messing with the standard formats

Thank you for your comments. My advice is that you should read more. Nothing poisonous is being done to the standard itself. The parts of the standard that are used for web fonts are unmolested when compared, e.g. to the glyph standards, etc.

Type developers tread a complex maze of non-standard interpretations of the standard formats where OS developers play every hidden card they have to improve the performance of fonts on their systems, often with disregard to; the standard, the courtesy of documentation, and the web.

You could consider this kind of technique a willful act of intrusion and endangerment and tell them to go to hell, fine. We prefer to work through these difficulties like agnostics, (and I admire you for how little you know on this topic).

Cheers!

Richard Fink's picture

@paul irish

This is stated as an interim solution, as I'd think foundries would be interested in licensing their fonts to work, securely, in 100% of supporting browsers today.

I think you've unintentionally hit the nail on the head. I don't think font producers - in the main - are much interested in licensing their fonts to work in 100% of browsers today. I've never, ever heard any enthusiasm for providing web fonts at all. And I don't think there will be much enthusiasm for it after WOFF and EOT are ubiquitous, either.

One thing I have heard regarding licensing for the web is that "We don't yet know what business model is going to work". And that therefore, judgment should be suspended while experimentation with different models goes forward.

Yet, the one experiment I have yet to see tried by any established commercial font producer would seem to me to be the first choice/no-brainer: take a few fonts with good screen quality and offer to license them for web use and see what happens.
Until such a test marketing occurs, anybody who waxes forth about "well, we don't know what will work" is simply full of hot air IMHO.

John Hudson's picture

James: I am just continually confounded at how much thought and effort goes into trying to protect web fonts from being used as system fonts given that casual pirates will probably always take the casual route and just google “fontname font rapidshare OR torrent”.

That's not my definition of 'casual piracy'. That's an intentional act to obtain a thing, not having a thing arrive on your computer because you visited a website.

But I don’t see a need for all these hacks because I think it silly to believe that anyone who will to make the effort to pirate web fonts would pay for fonts to begin with.

Exclusivity is a core value of a typeface. This is why clients pay more for exclusive use of a typeface than they do for non-exclusive use, and why retail licensors expect diminishing returns for a popular font: the more people who have a font, the less value it is perceived to have. Unlicensed use undermines this value, so whether the unlicensed user would or would not have paid for a license to begin with is irrelevant. It's especially irrelevant to my clients who are looking to use fonts on the web that are not available for licensing to other parties anyway. They are not interested in protecting sales, they are interested in protecting their investment in the exclusive value of those fonts.
___

Now, having said that, let me be clear that I'm not in favour of font obfuscation methods. The proper response to browsers that only support naked fonts for @font-face is not to support those browsers.

John Hudson's picture

Henry: I suggest you stop messing with the standard formats and keep waiting for a standard-conform web font technology that you like. Not having web fonts is not a big deal -- having intentionally corrupted data is a huge deal.

I'd agree with that.

One of the things that OpenType made possible was the cleaning up of a lot of hacked, non-standard font data that had proliferated during the 8-bit years.

Christopher Slye's picture

I don't think font producers - in the main - are much interested in licensing their fonts to work in 100% of browsers today. I've never, ever heard any enthusiasm for providing web fonts at all. And I don't think there will be much enthusiasm for it after WOFF and EOT are ubiquitous, either.

Wha?

Monotype's new service, along with Typekit and all the others, provide fonts that are compatible with virtually all browsers. I'm sure Monotype, Ascender, FontShop, et al. are quite enthusiastic about it. Quite a while ago, Adobe joined Monotype in Microsoft to support standardization of EOT, the goal of which was to get web fonts working in all browsers.

Rob O. Font's picture

JH> Now, having said that, let me be clear that I'm not in favour of font obfuscation methods.

Me neither it all sucks. When OT is Safest, you know what I mean.

Jh> The proper response to browsers that only support naked fonts for @font-face is not to support those browsers.

Now now. If we all felt that way about each browser maker's choice, we'd have nothing to @font-face to at all.

Cheers!

John Hudson's picture

David: ...we'd have nothing to @font-face to at all.

I'd say that, at the present time, there is precious little to which to @font-face, but a lot of people pretending that there is and trying to make us think that there is some kind of pressing imperative that obliges us to do in a matter of a few months -- using whatever hacks and compromises will get us to market -- what has clearly not been a pressing imperative for more than a decade. It's surely a good thing that web type is finally moving, but between total inertia and running blindly off a cliff there is a lot of leeway for the kind of movement that goes places. There is going to be a cross-browser, standard web font format, and I don't see the point of compromising either principles or data to support what will quickly be, in the context of that format, non-standard legacy solutions affecting a minority of users. I see no more reason to support 100% of current browsers than I did to support 100% of word processing and page layout applications that didn't handle Unicode text or could only access variants using PUA mappings.
___

For me, web fonts present something of a novel situation. For a dozen years, I've been making a lot of fonts that in one way or another wouldn't work in current software. I'd make them, ship them, and wait for the applications to support the features. Sometimes I took the long road, and had to propose characters to Unicode, get them approved and published in the standard, and wait for them to be supported in software before the font would work.

So it's quite amusing to be looking at a situation in which software makers have invented a web served font mechanism for which there are almost no fonts.

Frode Bo Helland's picture

Slightly off topic @John: I’ve seen way too many fonts designed with zero attention to how they behave in MS Office! That’s a definite dealbreaker for identities, at least if someone are going to use the fonts inhouse.

fontsquirrel's picture

This thread really makes me chuckle. Thanks guys.

paul.irish's picture

FWIW John Daggett (editor of the CSS3 Fonts spec) and font maestro at Mozilla gave his feedback on the details above:

Yeah, that should work fine I think. I would try printing under OSX, since that's where swizzling the PS name might matter. If the FF code changes in the future it will probably change towards the Chrome way of doing things, namely dropping the name table altogether so that we avoid all the nonsense associated with it on Windows.

John Hudson's picture

How is a a font identified without the name table? How is style linking handled without the name table?

Syndicate content Syndicate content