With all of the daily developments in the webfont discussion, the security of font files is a bit sidelined. For foundries, companies, and designers, the security of a font can have legal, competitive, and moral ramifications (which I won't cover here). A web-specific font format, like WOFF, may appear to offer consolation to foundries but relying on browser implementation of any feature is historically dire. I say watch your own ass(ets). I propose a server-side lock and key: Simple PHP Font securitY (SPiFY).
The basic, insecure @font-face has CSS specify a font file with its name and address out there in the naked. Any user with a little know-how can simply type in the address and download the font. I set out to put a chastity belt on it, giving the key only to it’s suitor: my trusted CSS. When a stranger tries to access the font nothing is downloaded, only a message shows up instead; let’s say license info or where to buy the font.
Note: I have removed the code as understanding how it works makes it vulnerable. Please comment or contact me if you would like to use the code yourself.
A demo of @font-face using my badly drawn Sharp Serif.
This isn’t foolproof but it is fun. I should just stress that you need to check the EULA of your commercial fonts or negotiate with the foundry, and present clients with the pros/cons of this solution.
There are plenty of other issues that accompany the use of @font-face. Compression is a biggy, and that’s something WOFF will help with.
Good resources for other issues:
8 Comments
7 November 2009
Great stuff Aaron.
In my presentation on Custom Fonts… Now (http://paulirish.com/customfonts/) I reviewed a few things that can be done to secure the font data (slides 34-39):
* deliver as data:uri
* data:uri fonts haven’t been proved to work in IE8
* mhtml fonts have not been seen working in ie6/7
* subset to what’s needed: http://www.twardoch.com/webfonts/
* segment across multiple files
* define allowed referrers
* cross-origin acccess control
* http://pastie.org/653265
8 November 2009
Thanks Paul!
You are indeed the expert, so I appreciate your points. What do you think of the php sessions idea? Does it work in concert with any of your solutions? I could see using sessions and data:uri, for example.
I’ve also been looking into my own compression to augment subsetting, but to no success yet. I’ve got fully functional fonts down to 30 kb, but that still leaves a bit too much FOUC.
Aaron.
22 December 2009
doesn’t this become moot if the user running the browser just snarfs the raw data that is coming in ?
22 December 2009
@robotarmy I assume by snarfing raw data you are referring to hacking the browser’s cache? The security of the cache is up to the browser, nothing we can do about it. If you can get something functional from my demo, do let me know!
29 May 2010
Just to keep things linked…
I’ve recently proposed a few modifications of the font file itself that prevent the font from being installed:
http://typophile.com/node/70404
10 June 2010
Nice trick, but security by obscurity never works. It’s like disabling the right click to prevent that someone “steals” you code. You just block the easy and obvious route.
edit: removed instructions for the bypass
3 August 2010
I would like to use it. May I?
7 August 2010
Hi Aaron, I actually need something like what you have created. May I use it as well?
Leave a Reply