views:

64

answers:

3

I am aware that using @font-face allows the browser to download a custom font and use it in a web page just like any system font.

What I want to know is if the browser encodes the font or uses it without exposing it?

Thanks

A: 

In most cases, the font file is exposed in that it is directly linked from your CSS file, and thus anyone intelligent enough can download the font and install it on their machine. This is partly why most commercial font licenses prohibit them from being used on websites with @font-face. But there are techniques that limit this. For example, check out the "Web Only" option on Font Squirrel's @font-face generator.

stevelove
A: 

@font-face tells your browser where to download the actual font.

For example, when using Google's web fonts, they give you CSS like this:

@font-face {
  font-family: 'Cantarell';
  font-style: normal;
  font-weight: normal;
  src: local('Cantarell'), url('http://themes.googleusercontent.com/font?kit=p5ydP_uWQ5lsFzcP_XVMEw') format('truetype');
}

If you open the url (http://themes.googleusercontent.com/font?kit=p5ydP_uWQ5lsFzcP_XVMEw) your browser will download the actual true type font file.

I've downloaded google's fonts using this method (so my Photoshop mock ups have the correct font).

Seth
+1  A: 

The browser cannot protect the source of the fonts. Once the information gets received by the browser, you can safely assume that the user will have full access to whatever you send it.

Thus the problem of keeping the fonts secure is done on either on the legal level (by choosing fonts which allows for embedding) or through server side obfuscation schemes. For instance, look at the fonts embedded through TypeKit:

@font-face {
    font-family:"rosewood-std-fill-1";
    src:url(data:font/opentype;base64,d09GRgABAAAAAEa4ABMAAAAA2XwA.....);
    font-style:normal;
    font-weight:400;
}

The font is obfuscated through a base64 encoding process. Additionally, the font is split in two and the number of glyphs are limited to only the ones needed by the website.

On the other hand, looking at FontSquirrel and Google Font API @font-face kits, you can see that the actual source of the font is sent to the user - no obfuscation required. Additionally, font owners may demand some form of attribution, such as

If the font is a free font ($0.00 license fee), you may use this font for Font-Face embedding, but only if you put a link to www.exljbris.nl on your page and/or put this notice

/* A font by Jos Buivenga (exljbris) -> www.exljbris.com */ 

in your CSS file as near as possible to the piece of code that declares the Font-Face embedding of this font.

seen in this license. Therefore, from all of these, we can safely conclude that the problem of font security does not happen on the client side, but rather falls on the shoulder of the developer, and so browsers cannot and do not do anything to stop users from gaining access to these fonts.

Yi Jiang
The base64 encoding isn't obfuscation, it's a means of eliminating the need to make an additional HTTP request for the font file while maintaining the "text/css" MIME type.
Stan Rogers
@Stan Really, I can't think of any other reason why. Typekit only allows up to five fonts anyway, so the HTTP request overhead isn't *that* significant. Do you have any documents to back that up?`
Yi Jiang
*Every* HTTP request is significant, and base64 is a content-transfer encoding for which everyone has a decoder. The aim is not obfuscation -- the alternative is a binary transfer, which can't be embedded on the stylesheet. You may choose to force a request for a font file if you wish; Typekit has chosen not to. (I use the same technique for small repeated background images.) They've given you a file that is more accessible to a user than a binary would be (no hunting through cache, just copy from the CSS file, save and convert).
Stan Rogers