webfont name obfuscation #165

anthrotype · 2014-09-23T10:47:59Z

Hello,

I am trying to find a reliable method to 'obfuscate' the name table of TTF/OTF fonts when these are used as webfonts, in order to prevent users from installing them locally as desktop fonts.

FontTool's subset.py already drops all nameIDs except 1 (famliy) and 2 (subfamily) by default, thus making the subset fonts impossible to install and use on both Windows and OSX (I haven't tested Linux yet).

A problem of dropping all names except 1 and 2 is that the subset fonts can no longer be converted to EOT format, since they lack some required names. EOT conversion apparently requires all nameIDs from 1 to 6 in order to work, as discussed here.

An alternative (or concurrent) approach to dropping all names except 1&2, could be to replace the names with either empty or dummy strings, like FontSquirrel currently does with its "WebOnly" option**.

By comparing the name table generated through FontSquirrel with the original one, I tried to reconstruct the 'recipe' that FontSquirrel uses:

1) for the Mac (plaformID=1):
    1.1) set the "family" (nameID=1) and "uniqueID" (nameID=3) records to an empty "" string;
    1.2) set the "subfamily" (nameID=2) and "postscript name" (nameID=6) records to a "\x7f" string
         (i.e. the "DELETE" control character U+007F);
    1.3) keep the "full name" (nameID=4) and append " Webfont" to it;
    1.4) discard all the mac nameIDs in the range 0-255 except for 1, 2, 3, 4, and 6;
2) for Windows (platformID=3):
    2.1) set the "family" (1) and "full name" (4) records to the dummy string ".\x7f" (period + U+007F),
         encoded as UTF-16 Big Endian;
    2.2) set the "subfamily" (2) and "uniqueID" (3) records to an empty "" string;
    2.3) set the "postscript name" (6) to the dummy string "\x7f" (this time without period);
    2.4) keep all the other Windows name records.

Something similar to this could be easily implemented as an "--obfuscate-name" option to pyftsubset.
I wonder if others would be interested too.

Cheers,

Cosimo

** Another source of info on webfont name obfuscation is Paul Irish's Typophile post and the discussion that follows.

The text was updated successfully, but these errors were encountered:

behdad · 2014-09-23T10:58:06Z

I like a mode to keep the minimal entries that allow full webfont use, and a mode that allows installs as well. Adding bogus entries is something I like to avoid if possible, but am willing to consider. Or does adding enough names to make EOT happy make the font fully installable? In that case, bogus names would help, yes.

anthrotype · 2014-09-23T11:42:54Z

does adding enough names to make EOT happy make the font fully installable?

Unfortunately yes, at least on Windows.

However, a further problem is that it's not just the subset font with names 1 & 2 that produces a corrupt EOT; even a FontSquirrel-obfuscated TTF/OTF -- using the above mentioned procedure --, cannot be used as the source for a working EOT**.

Interestingly, if you inspect the header of FontSquirrel's EOT fonts (I used eot-utils), you'll see that they do contain the full set of basic names, whereas their TTF and WOFF versions contain the obfuscated names.

So, there seems to be a paradox here. If you make the font completely uninstallable, you also prevent it to be convertible to EOT. If you make it convertible to EOT, they become installable as well.

As far as I see it, one solution could be to fully 'obfuscate' only the raw TTF/OTF and WOFF versions (making the former uninstallable on desktop), while leaving all the basic names (1-6) in a temporary file used for EOT conversion.

Another solution would be to only mildly 'obfuscate' the names, using some combination of white spaces or bogus strings, which, unlike the FontSquirrel-like obfuscation, does not prevent that font from being technically installable by the operating system, but which will still make it unusable: i.e., it will show up in the menu with some garbled label and could not accommodate more than one font with the same bogus names. This way one could have the same semi-obfuscated TTF/OTF be the source for both WOFF and EOT webfonts.

** By the way, I'm using sfntly to convert to EOT. The other (win only) tool EOTFAST aborts whenever the font is missing basic names, whereas sfntly's sfnttool.jar does not print any warning but produces an EOT which fails to be loaded by Internet Explorer.

fsi-jens · 2014-09-23T12:27:31Z

So, there seems to be a paradox here. If you make the font completely uninstallable, you also prevent it to be convertible to EOT. If you make it convertible to EOT, they become installable as well.

It's definitely possible to make a working EOT from an obfuscated uninstallable TTF. I'm not sure if I'm allowed to comment on the 'how' :/

anthrotype · 2014-09-23T12:35:40Z

Regardless of how you technically make a working EOT from an obfuscated uninstallable TTF (which I can try to figure out on my own), the question remains:

do you see any advantage of including an obfuscation method such as the one described above inside the current fontTool's subset.py?

Or maybe, if I read between the lines, do you fear that introducing this as part of an open source project could make it easier for people to reverse?

fsi-jens · 2014-09-24T13:56:00Z

I think all the different name table obfuscation methods can be reversed with the same effort ;) I'm just not sure if my employer wants our specific method to be publicly documented.

Producers of commercial or proprietary fonts will surely see the availability of obfuscation as an advantage, other parties probably don't care.

anthrotype · 2014-09-25T14:58:53Z

After some experiments, I found an obfuscation method that produces uninstallable fonts on Windows and OS X but doesn't break EOT conversion: #170

I converted the obfuscated TTF fonts to EOT using sfntly (EOTFAST still fails to load them), and tested them successfully on Internet Explorer 8 and 11.

behdad · 2014-09-25T15:01:34Z

Cool. Thanks! BTW, if you feel like porting EOT or WOFF2 to fonttools, go for it ;).

anthrotype · 2014-09-25T15:04:58Z

you know, I was really thinking about that...

behdad · 2015-08-19T14:35:44Z

And, WOFF2 is in master now. Thanks @anthrotype!

Arno-Enslin · 2017-07-17T11:31:42Z

pyftsubset removes the namerecords for plaformID 1 (Mac) completely. I assume, that you have checked to see, whether none of these records is needed on the Mac. Would you confirm that, please? (You only have written, that you have checked to see, whether the fonts with the obfuscated names can converted to eot with sfntly and whether they are uninstallable on both platforms, but not, whether they work in IE 8 and 11 on the Mac, but not on Windows only. The Fontsquirell webfont generator still doesn't remove the namerecords for plaformID 1. And I don't have a Mac. So I cannot check that by myself.)

By the way, I have tried your Python bindings for sfntly, anthrotype. Works fine, thanks! But a solution, that does not require Java would be cool. (I have installed Java only because of sfntly. And if sfntly would be integrated into the AFDKO, a pure Python solution would be cleaner for two reasons: First, because the Java installer has a file size of round about 60 MB and a pre-installation contained in the AFDKO would enlarge the size of the AFDKO very much. [There are some scripts from Ken Lunde, that already require a Perl installation, but I assume, that these scripts could also be written in Python.] Second: In my imagination Java is not as secure as Python with regard to malware. With regard to the second point I may be totally wrong.)

My concerns with regard to the AFDKO and the FontTools are: I am mainly a user, but not a DAU. With regard to the technical aspects of font development there are many type designers, for which the installation, build process and the use of the AFDKO seem to be harder than for myself. So I am afraid, that these excellent tools are mainly used by developers, but not by artistical creative people. On typografie.info for example is a type designer, from which I know, that he is not fallen on the head with regard to the technical aspects of font development, but I was not able to make the AFDKO tasty for him, although I tried more than one time.

davelab6 · 2017-07-17T12:41:22Z

The Mac name IDs are for the pre Mac OS X macOS and thus mostly obsolete, except for MS Word for OS X which still used them in recent versions

…

On Jul 17, 2017 7:31 AM, "Arno-Enslin" ***@***.***> wrote: pyftsubset removes the namerecords for plaformID 1 (Mac) completely. I assume, that you have checked to see, whether none of these records is needed on the Mac. *Would you confirm that, please?* (You only have written, that you have checked to see, whether the fonts with the obfuscated names can converted to eot with sfntly and whether they are uninstallable on both platforms, but not, whether they work in IE 8 and 11 on the Mac, but not on Windows only. The Fontsquirell webfont generator still doesn't remove the namerecords for plaformID 1. And I don't have a Mac. So I cannot check that by myself.) By the way, I have tried your Python bindings for sfntly, anthrotype. Works fine, thanks! But a solution, that does not require Java would be cool. (I have installed Java only because of sfntly. And if sfntly would be integrated into the AFDKO, a pure Python solution would be cleaner for two reasons: First, because the Java installer has a file size of round about 60 MB and a pre-installation contained in the AFDKO would enlarge the size of the AFDKO very much. [There are some scripts from Ken Lunde, that already require a Perl installation, but I assume, that these scripts could also be written in Python.] Second: In my imagination Java is not as secure as Python with regard to malware. With regard to the second point I may be totally wrong.) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#165 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAP9yzWwHZxraHs5iA4ikNHK4Ccm3Hmuks5sO0YegaJpZM4Clj1I> .

anthrotype closed this as completed Sep 26, 2014

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

webfont name obfuscation #165

webfont name obfuscation #165

webfont name obfuscation #165

webfont name obfuscation #165

Comments