Web Font Security

Josh Nychuk

I'm wondering if there are industry standard security measures for protecting self-hosted web fonts?

I've designed the font myself, and would like to use it on my website without someone having the ability to pirate it. From what I've read even the biggest web font providers cannot completely prevent font piracy, so I'm hoping to make it as bullet-proof as possible.

Lars Schwarz

Simple answer: There is none. Even with so called obfuscation or using CDNs that only serve to specific requests, it's still pretty easy to grab any font. If the browser can use and render it, everyone else can, too. However this 2 features (obfuscation and a properly configured CDN) is something you should consider of course.

Jens Kutilek

Use a subset of your font that just contains the glyphs actually needed for your site. Of course, this is hard if you have dynamic content.

Josh Nychuk

Thanks Lars and Jens.

@Lars Schwarz could you point me to a well-explained tutorial covering font obfuscation and properly configuring CDN?

Lastly, I've purchased web fonts with rights for self-hosting and they involved configuring an .htaccess file. Does anyone recommend that method and can provide a tutorial for setup?

Thanks!

SiDaniels

Security through obfuscation requires obfuscating the obfuscation techniques.

Thierry Blancpain

Hey @Joshnychuk! This might not be what you’re looking for really, but my (strongly held) opinion is that trying to prevent someone downloading your webfonts is impossible, and thus lost time that you can spend on way better things.

If someone wants to download it they can download it, no matter what you do against it. Subsetting is always a good idea (to optimize load times) but other than that, I wouldn’t spend a single minute on any of the techniques.

Roel Nieskens

Serving your webfonts only in the WOFF and WOFF2 formats is maybe your best bet. As with all other options, people who know their stuff will be able to pirate them anyway, but the Average Joe won't be able to simply download and install them.

Josh Nychuk

Thanks @Thierry Blancpain and @Roel Nieskens this sounds like good advice. 

Luke Freeman

Now days font converting can be done online, whats stopping a user converting a WOFF or WOFF2 into a otf or ttf.

I have came across some sites that have very good protection preventing a user ripping a webfont. 

Site examples:
http://www.filipmatejicek.info/

Peter Constable

Luke Freeman said:

...
I have came across some sites that have very good protection preventing a user ripping a webfont. 

Site examples:
http://www.filipmatejicek.info/

That site is embedding WOFF data directly within the @font-face rule definition, using base64 encoding --- which will expand the size of the data probably by a factor of 4.

Grzegorz Luk (gluk)

Luke Freeman said:

I have came across some sites that have very good protection preventing a user ripping a webfont. 

Advanced user can download embedded as Base64 Data-URI font too.

Thierry Blancpain

Additionally, all your regular users won’t be able to benefit from caching and will have to re-download the Base64 data every time they visit, making your site slower to load to repeat visitors. 

There’s situations where this is warranted and useful, but not very often.

Luke Freeman

All make valid points. Not many advanced users out there, at least the method makes it harder "prevention is better than cure".

Another site I suggest just for type testing
http://www.aisforapple.fr/fonts/david

Johannes Neumeier

Joshnychuk said:

Lastly, I've purchased web fonts with rights for self-hosting and they involved configuring an .htaccess file. Does anyone recommend that method and can provide a tutorial for setup?

Not sure what this is referring to, but from my technical understanding this sounds like you are maybe confusing or misremember something - if the fonts render as webfonts in a browser anybody can rip them, no matter what your server configuration. A .htaccess might be used to properly configure webfont mime types, for example.

In case I am mistaken, I would be very curious about what this setup achieves and how.

My guess is this (and any other method of obfuscation) mostly provides headaches to paying clients.

AbrahamLee

gluk said:

Luke Freeman said:

I have came across some sites that have very good protection preventing a user ripping a webfont. 

Advanced user can download embedded as Base64 Data-URI font too.

... or just copy+paste the text data directly into a text editor and use some basic programming to re-encode it as a usable binary file. I've done it just to prove it can be done. It's a nice idea that *most* people won't know what to do with, but it's not that hard to make a real font out of the data, unfortunately.

Thierry Blancpain

Johannes Neumeier said:

Joshnychuk said:

Lastly, I've purchased web fonts with rights for self-hosting and they involved configuring an .htaccess file. Does anyone recommend that method and can provide a tutorial for setup?

Not sure what this is referring to, but from my technical understanding this sounds like you are maybe confusing or misremember something - if the fonts render as webfonts in a browser anybody can rip them, no matter what your server configuration. A .htaccess might be used to properly configure webfont mime types, for example.

In case I am mistaken, I would be very curious about what this setup achieves and how.

My guess is this (and any other method of obfuscation) mostly provides headaches to paying clients.

Certain foundries require this, because ¯\_(ツ)_/¯

It hinders cross-domain font usage and (somewhat) makes downloading them harder because it restricts access to local referrers. But again, the people who download them from websites can do so anyway, and everyone else can just go to Google and get them from there.

Ori Ben-Dor

Is this a real problem? How often do people, who would otherwise purchase a font, rip it from a website instead?

Peter Constable

Re .htaccess files, I'm guessing that's related to this:

"For font loads, user agents must use the potentially CORS-enabled fetch method defined by the [HTML5] specification for URL's defined within @font-face rules. When fetching, user agents must use "Anonymous" mode, set the referrer source to the stylesheet's URL and set the origin to the URL of the containing document.

"The implications of this for authors are that fonts will typically not be loaded cross-origin unless authors specifically takes steps to permit cross-origin loads. Sites can explicitly allow cross-site loading of font data using the Access-Control-Allow-Origin HTTP header."

http://www.w3.org/TR/css-fonts-3/#font-fetching-requirements 

Jack Jennings

And worth noting that CORS is only something that is implemented in browsers, and is mostly for preventing reuse of some asset directly on another website, but is not an IP protection method. At best it's use in this context is a hack, and can be easily circumvented using basic tools like curl.

Jack Jennings

An parallel example is all of the websites from the aughts that would display an alternate image if you tried to directly link to an image hosted on their server from another domain. There was still nothing that would stop you from downloading the image, uploading it to your own server, and linking to that version. Nothing more special happening for fonts today.

SiDaniels

"I will build a great web font DRM solution — and nobody builds DRM better than me, believe me —and I'll build it very inexpensively. I will build a great, great DRM solution for our web fonts, and I will make the W3C pay for it. Mark my words."

Justin Penner

Hoefler & Co used to have a clever system where each font was split into two separate font files, with half the glyphs in each. Then the browser would seamlessly merge them through the use of a font stack like `font-family: GothamA, GothamB;`. I noticed it once when one of the fonts didn't load properly and all the text was a random mix of an H&Co font and a system font.

Of course, finding a pirated copy of Gotham is as easy as Googling "gotham font" and clicking one of the first links that come up. Piracy on its own doesn't bother me too much, but since Google prioritizes pirate font sites, there are also an enormous number of font users who are downloading pirated fonts unintentionally, because the site told them it's a free font, and Google told them it's a trustworthy site by putting it (and 5 or 6 other pirate sites) in the first 10 search results.

Should we be lobbying Google to improve their search results? If you search for any popular movies, books, or music, you don't generally find the top 10 results filled with pirate links.

jeremy tribby

the hoefler method was clever; I think that + CORS is probably a reasonably effective deterrent even though it’s ultimately circumventable and the fonts could be found elsewhere. anti-piracy efforts can have negative consequences though. @Thierry Blancpain made a good point in another thread on this topic which is that pirates may one day become your customer. in the meantime, you haven’t lost a sale, because they were never going to pay in the first place. what is actually gained by locking things down?

Michael Rafailyk

Justin Penner said:
split into two separate font files, with half the glyphs in each

This approach requires care in which glyphs go into first file or second, because it can break OpenType features related to glyphs if those glyphs are missing. Although for sure, all these exclusions can be automated during export.

Enrico Sogari

Justin Penner said:

Hoefler & Co used to have a clever system where each font was split into two separate font files, with half the glyphs in each. Then the browser would seamlessly merge them through the use of a font stack like `font-family: GothamA, GothamB;.

Pretty smart approach.

Should we be lobbying Google to improve their search results? If you search for any popular movies, books, or music, you don't generally find the top 10 results filled with pirate links.

YES absolutely.

John Hudson

Hoefler & Co used to have a clever system where each font was split into two separate font files, with half the glyphs in each. Then the browser would seamlessly merge them through the use of a font stack like `font-family: GothamA, GothamB;.

That implies no interaction between the two glyph sets: no kerning, no GSUB contextual crossover, no anchoring of marks in one font with bases in the other.

I suspect this sort of technique is feasible with pretty basic Latin fonts, if the two sets are carefully selected to minimise the impact of lack of kerning, but it isn’t a viable option for any complex script or for fonts making even moderately sophisticated use of OTL layout features.

[Also, I believe this was in context of H&Co’s webfont service, i.e. it was within a delivery system controlled by H&Co, so not dependent on the licensee understanding what they needed to do to get the fonts to work. Or was this technique also imposed on self-hosting licensees?]

Michael Rafailyk

.

Christopher Slye

FWIW Typekit also employed split-font delivery, at least in some cases. Even now I have an active kit with “myriad-pro-1” and “myriad-pro-2”. A subsetting thing? I forget.

Johannes Neumeier

Seems not to be the case any more. Weirdly enough though there is a distinct file for every "space" of a style, yet the counterpart contains everything*. Not to mention using a single file for every style, and woff instead of woff2, ending up with a whopping 7.5MB and 200 individual http requests for fonts alone on a family page. Hardly a positive benchmark in any technical regard.

*of course this is speculative conjecture and I would not in my wildest dream dare inspecting the unlicensed intellectual property of our monopoly overlords.

Michael Rafailyk

Johannes Neumeier said:

200 individual http requests for fonts alone on a family page. Hardly a positive benchmark in any technical regard.

In that particular case (with a files of such a small size), it would be much more efficient to convert all woff to base64 strings (it should be automated, of course) and store it in several css files (let's say 100-500 kb each), which will significantly reduce the number of requests.

John Butler

We have the bandwidth now to return to bitmap fonts, an idea promoted by Letterror for decades. Is there an existing way to do it on a website?