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)

John Hudson's picture

Frank, I think I can safely say that most of the fonts I have created have been made with altogether too much attention to how they behave in MS Office. :)

ralf h.'s picture

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

You set this all up in the CSS and the font is just identified as a reference to a file.

John Hudson's picture

Thanks, Ralf. I figured it was like that.

Heh, I love the idea that one could set up CSS to style link italic text as letterspaced fraktur. :)

Richard Fink's picture

@johnhudson

The future isn't what it used to be, that's for sure.

kentlew's picture

> Heh, I love the idea that one could set up CSS to style link italic text as letterspaced fraktur. :)

Goudy would love it, eh? Sheepstealer.com anyone? ;-)

Thomas Phinney's picture

John: Currently my blog is using Raleigh for upright and Janson for italics....

T

VBM's picture

Isn't this really just a cheap exploit and not truly obfuscation? I think these fonts could still be opened in Fontlab et al after conversion and regenerated as installable fonts making all your efforts in deleting fields a waste of time. I know of at least 2 glyph extractors that won't be affected by this already.

Michel Boyer's picture

Thomas,

In your css file http://www.thomasphinney.com/wp-content/themes/blog-one/style.css I got a link for you italic, "opened" it with Safari 4.0.5 in OS X 10.5.8, which in fact saved a file in Downloads, a file that I could open directly with my prefered font editor. I did not get Janson. I can see the opentype tables, etc. It would no doubt be easy to save it as an installable font.

Can someone explain to me what the protection mechanism is supposed to be? If the file I saved had been encrypted with a random key sent by my browser and only known to it, that would have been a much better protection. No need for a safe encryption algorithm, something fast would be enough.

Michel

Arno Enslin's picture

If the file I saved had been encrypted with a random key sent by my browser and only known to it, that would have been a much better protection.

That’s not the job of the browser developers.

-----------

Changing the name table is idiotic. It is absolute no protection and easily to repair. It is so naive to think, that this could protect fonts against piracy. Even a font editor is not needed for correcting the name table, TTX is enough.

fontsquirrel's picture

What you fellows don't get is that you are not the people this "hack" is aimed at. I too figured out the workflow to steal Typekit fonts, ascender, fonts.com etc. It isn't hard. But it is specialized knowledge and specialized tools. How many scrapbookers, web developers and even mildly sophisticated "hackers" know 1) What those tools are and 2) How a font is actually put together?

This is not fortress-style protection. Isn't meant to be. It is garden fence protection. It keeps "normal people" off the grass.

Michel Boyer's picture

FontSquirrel

Do you really think it is harder than extracting a font from an unprotected pdf?

fontsquirrel's picture

Well, I don't know. I've never tried. What do you do, extract the PDF through FontForge?

Tim Ahrens's picture

Michel: Do you really think it is harder than extracting a font from an unprotected pdf?

What's the relevance of this comparison?

Si_Daniels's picture

>Do you really think it is harder than extracting a font from an unprotected pdf?

I think you hit the nail on the head. 98.6% of font designers are okay with PDF embedding (unprotected or otherwise) so if these hacks provide a similar level of protection against truly casual drag-and-drop font re-use then they're okay with these @font-face schemes.

Michel Boyer's picture

In fact, the fontname is also extracted from the unprotected pdf, so the font is ready to be saved (with missing characters, no kerning table etc). On the other hand, with what I got from font-face above, the hacker needs to adjust the names, which is more work indeed, and that also requires some knowledge; however, less characters are likely to be missing from the resulting font, if any, and the useful tables are there (GPOS: kern, GSUB: aalt frac, onum, lnum, pnum, etc.). I can't imagine a font producer that writes in his EULA that his font may not be embedded and then makes his font available with font-face unless there is something I am missing (some bit that needed to be checked and that the sofware I used did not check, for instance, because it is not up to date).

edit: this post was written before the two previous posts.

fontsquirrel's picture

I think you hit the nail on the head. 98.6% of font designers are okay with PDF embedding (unprotected or otherwise) so if these hacks provide a similar level of protection against truly casual drag-and-drop font re-use then they're okay with these @font-face schemes.

Wow, I never made the connection, but Simon you are right. If the comparison holds up that PDF embedding is approximate to font-face embedding... well, that is big news for getting designers on board with this idea.

Christopher Slye's picture

Like clockwork, this straw man argument pops up: This will not stop piracy.

Nobody is trying to stop piracy. We are trying to reduce piracy, and much piracy is unintentional, because people don't know what they're doing is prohibited. If I own 100 acres of open space and don't put a fence around it, should I be surprised when people wander onto my property? I can put up a simple fence with some signs and significantly reduce trespassing -- and I can now go up to someone I find on my property and be more confident that they know what they're doing is wrong.

A message to the font geeks: Foundries are well aware that you can extract a font out of EOT or WOFF or PDF. It's not news.

Michel Boyer's picture

I can put up a simple fence with some signs and significantly reduce trespassing

Some people would also put a lock on the gate.

Arno Enslin's picture

@ Christopher

If someone downloads a web font, he either wants to use it as web font or as font installed on his system. If he wants to use it as web font, the messed up name table does not need to be corrected and the woff file not to be converted. But if he is able to convert the woff file, he also will make out, how to correct the name table. And if he does not make it out, he asks somebody to do that for him. Manipulating the name table as protection is useless. Except from that you violate specifications. It is not the job of the browser developers to care about violated specifications. There is no guarantee, that fonts with manipulated name tables work in all browsers (and other media/programs, that can access/display/print web content / CSS formatted markup languages), that support web font embedding.

Christopher Slye's picture

Manipulating the name table as protection is useless. Except from that you violate specifications.

Actually, AFAIK the technique described here is not a violation of the OpenType spec.

It doesn't contribute much to the discussion to declare this approach "useless". I haven't tested it myself, but if it does indeed make the font useless on the desktop but useful in a browser, then that is perhaps useful to someone.

Arno Enslin's picture

@ Christopher
From the OpenType spec – Name ID 2 (Font Subfamily name): The Font Subfamily name distiguishes the font in a group with the same Font Family name (name ID 1). This is assumed to address style (italic, oblique) and weight (light, bold, black, etc.). A font with no particular differences in weight or style (e.g. medium weight, not italic and fsSelection bit 6 set) should have the string “Regular” stored in this position.

From the TrueType spec 1.66 – Name ID 2 (Font Subfamily name): for purposes of definition, this is assumed to address style (italic, oblique) and weight (light, bold, black, etc.) only. A font with no particular differences in weight or style (e.g. medium weight, not italic and fsSelection bit 6 set) should have the string “Regular” stored in this position.

The difference is the word only.

If you follow the TT spec, you violate the specification. If you follow the OT spec, you violate the specification, because name ID 6 should be identically with the PS name in the CFF-table, if present.

Except from that using empty strings is not in the intention of the specification.

And with regard to name ID 6: If no name ID 6 is present, then there is no defined method for invoking this font on a PostScript interpreter.

So, what happens, if I want to print a web page on a PS printer, especially if all web fonts have the same name string there and if the fonts are in the printer cache, which probably could happen?

Manipulating the name table smells like trouble. You cannot know, if it works with all programs for which web fonts are intended to be used – all programs, that can display CSS-formatted markup. Those programs are not necessarily web browsers. (Well, Firefox is a browser, but its skin can be formatted with the help of CSS embedded web fonts. What is with other programs, that base on XUL and other markup languages?)

Jack B. Nimblest Jr.'s picture

>...if I want to print a web page on a PS printer, especially if all web fonts have the same name string...

Did PS become part of the web standard at some point, and I missed it?

Cheers!

k.l.'s picture

@ "Arno Enslin"
Nitpicking. Name table obfuscation intends to produce fonts that are not entirely complete/correct and thus of limited use. Whether such fonts "violate" the spec or not is a moot point. Whether this is a good idea or not depends on whether or not you do or do not want to achieve certain effects.
And the argument which you are using against Mr Slye and Mr Roberts, pointing to possible (mere hypothesis as of yet!) printing issues, is something that has been raised by Mr Roberts and Mr Slye first when they asked, "Have you tested printing to PostScript and non-PostScript printers, and to PDF?" See their comments above.

Michel Boyer's picture

A message to the font geeks: Foundries are well aware that you can extract a font out of EOT or WOFF or PDF. It's not news.

Christopher

I was surprised that it was so easy to get those files on the desktop in the first place; if they had been in some hard to find cache, I would not have mentioned it. Now that I get instead of a file an "Access denied" with what a "naive user" could do, I feel much better about your scheme. Hard to believe that till yesterday the door had been left wide open!

Michel

Arno Enslin's picture

Did PS become part of the web standard at some point, and I missed it?

Web standard? If you mean the specifications of CSS and HTML, it is possible to provide CSS for printers only. You even can format web documents in a way, that the content is visible in print only – except you turn of CSS.

@ k.l.

It is not a moot point, if you don’t know exactly the consequences of violating specifications. Except from that I miss the relation between the level of protection and the violation of specifications in this case. The hurdle to access a font is slightly higher only. The pirate still has to convert woff to ttf or otf (actually from the command line). If he is able to do that, he will also be able to edit the name table or to ask someone who is able to do that.

I think I could write a small program, that makes use of TTX and automates the process of correcting the name table in a way, that the font is installable. Manipulating the name table is not a protection, but a joke.

fontsquirrel's picture

Hey look! I can download the entire H+FJ library just by Googling "hfj fonts torrent." I think you are barking up the wrong tree Arno.

Arno Enslin's picture

@ fontsquirrel

Torrent? What’s that? I live in times of rapidshare and megaupload. But you are right. Sooner or later every font floats around. Only those people, that can’t wait and can’t get enough, extract and hack fonts. And for these people a manipulated name table is no hurdle.

By the way, manipulating the name table can have the negative effect, that people, that correct the name table, don’t put the original font names in it. More people will learn, how to set font names. And, I may be wrong, in some countries primary the name is copyright protected. It may be, that it is harder to sue then.

However, in my opinion web fonts are primary interesting for that, for which they are intended – embedding them in CSS, because if they are fragmented, their use outside the web is limited. And unfragmenting the parts requires much more knowledge than changing the name table. So, if the web fonts are pirated for the use in the web, there even is no need to correct the name table.

fontsquirrel's picture

Fragmented fonts were a clever hack devised by Typekit. It has several disadvantages however: 1) It breaks in Opera 2) Breaks some advanced CSS properties like text-shadow in Safari.

Richard Fink's picture

@arno

Thanks for doing the spec work - I was hoping someone would look closely and save me the trouble. But the problem is, now I have to double-check you. Responsible journalism lives. Sort of.

@christopherslye

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.

You are right. But please don't tell me there wasn't/isn't a lot of fear and apprehension. Resentment, too. I'm not judging, just commenting. And reacting.
Did I miss something? Was the font community urging browser makers to implement @font-face?
No. But the browser makers did and this forced decisions. Now that those decisions have been made, if there wasn't some enthusiasm about engaging with customers for web fonts I would wonder about the emotional health of those involved. Even though that engagement is a little tentative and skeptical and conditional - with the obfuscation and whatnot.

But what if the skeptics are right? And the whole font services thing is just a ploy to lure font designers out into the open so all the "information wants to be free" types can shoot them down like a bunch of turkeys?

Gobble gobble.

One thing I can tell you for sure: if you want web designers to respect you, you have to respect them and every font designer who wants to do business on the web effectively needs to have a blog or some equivalent line of communication to field customer inquiries about their fonts. Independent of whatever mega-site or service might be selling your stuff. Look, I can't prove this - at least not yet - but it's my hunch that responsiveness and accountability is going to go a long way.

@sii

98.6%?

rich

Jack B. Nimblest Jr.'s picture

>I think you are barking up the wrong tree Arno.

I don't see the relationship between the acts required to protect ones fonts from free downloads and/or their use as unlicensed font software, and the kinds of things one might do to protect ones fonts and licensed authoring users while ones font software products are being downloaded to unknowing end users?

Cranberry Blog will cover this and other ways to steal fonts, if I have time after the kevlar feathers are finished.

Cheers!

fontsquirrel's picture

David, I have no idea what you just said. Heh.

eliason's picture

Maybe there is something to obfuscation after all! :-)

fontsquirrel's picture

Nice Craig. You made me laugh out loud.

Arno Enslin's picture

David, I have no idea what you just said. Heh.

And I thought, it was my poor English.

There shall in that time be rumors of things going astray, erm, and there shall be a great confusion as to where things really are, and nobody will really know where lieth those little things with the sort of raffia-work base, that has an attachment. At that time, a friend shall lose his friend's hammer, and the young shall not know where lieth the things possessed by their fathers that their fathers put there only just the night before, about eight O'clock.

Christopher Slye's picture

But please don't tell me there wasn't/isn't a lot of fear and apprehension. Resentment, too. I'm not judging, just commenting. And reacting. Did I miss something? Was the font community urging browser makers to implement @font-face? No. But the browser makers did and this forced decisions.

Just remember that @font-face was around for quite a long time in IE for EOT (and in Netscape Navigator, heh). To be quite honest I wasn't paying attention when that was rolled out, but I don't remember a lot of FUD over EOT. Of course you're thinking of @font-face for raw fonts, which did generate a lot of anxiety, but that was not because of web fonts generally, but because they weren't protected in Safari, et al. Would there have been anxiety if all the other browsers had suddenly rolled out support for EOT? I think not.

The subscription services are, IMO, a great solution to the problems that foundries had with raw font linking. I think most foundries would have liked it if the other browsers added support for EOT, too, but it wasn't to be. If anything, the foundries weren't paying attention and should have done a better job of planning and campaigning for web fonts much earlier, but I don't think it was out of fear. I think it was just inertia.

Arno Enslin's picture

@ Christopher

Why are embedded fonts less protected with Safari? Do you think, base64 is any hurdle?

This is from a Typekit CSS displayed in Firefox. What’s protected there?

@font-face {
font-family: "font-family-NumberOfBlablaFont";
src: url(data:font/woff;base64,BlablaFontCode);
font-style: normal;
font-weight: 700;
}

fontsquirrel's picture

I think Christopher's point is that since Safari and Firefox support raw font linking, they offer no hurdles whatsoever. His point is that EOT files at least aren't installable and therefore less likely to be stolen. I agree with you that these hurdles are insignificant for anyone actively looking to steal fonts. But these people are not the ones we are protecting our fonts from.

Permit me to classify end users in three categories.

1. Honest end users who try hard to honor EULAs. They may *perhaps* download something to learn about it, but would never just steal and install. My experience tells me this is 70%-80%+ of the people out there.

2. Casual thieves, who would take if the opportunity presented itself and there wasn't much work involved. 20%? (that seems too high)

3. Dedicated hackers, who could run circles around you, laughing at your silly attempts to stop them. <1%

Obviously foundries would love to control all theft, but realize that the digital nature of fonts makes that impossible. Therefore, move on to the next best thing and raise the difficulty in stealing them. I honestly think that this scheme covers 99%+ of end users.

From what I understand, Mr. Berlow would also like to add detailed permissions to the font, so that he would have legal protection as well... (think of a Font Bureau font-sniffing bot, scouring the internet to see if you are honoring your EULA.) :-)

Jack B. Nimblest Jr.'s picture

>...(think of a Font Bureau font-sniffing bot, scouring the internet to see if you are honoring your EULA.) :-)

Not almost entirely incorrect I'm afraid; You might have me confused with someone in the in-crowd supporting woff's private data block?

>From what I understand, Mr. Berlow would also like to add detailed permissions to the font, so that he would have legal protection as well...

What Mr. Berlow wants primarily to add is recommendations meta data, so authors can find out what fonts they need to use (to-the-property), and end users can sniff around at authorley type behavior.

It should be obvious to you, that when the tumult over goofy browser rendering ends, there will be a "next" tumult, or is one-tumult-at-a-time far enough for you to look? ;)

As a 'commercial' vendor, I feel we have this already in hand, (preventing bad matches between users/use and fonts), and are likely to start swinging it around to our advantage. I'm wondering when the 'non-commercial' vendors are going to catch up otherwise, i.e. without a standard?

Cheers!

fontsquirrel's picture

Does anyone here speak Berlow?

Not almost entirely incorrect I'm afraid; You might have me confused with someone in the in-crowd supporting woff's private data block?

So am I right, or am I wrong? I am almost not entirely somewhat possibly sure what you mean :-)

What Mr. Berlow wants primarily to add is recommendations meta data, so authors can find out what fonts they need to use (to-the-property), and end users can sniff around at authorley type behavior.

Not following. Who are the authors and who are the end-users? If authors are font designers, then why do they need to "find out what fonts they need to use?" And what is "authorley type behavior?"

It should be obvious to you, that when the tumult over goofy browser rendering ends, there will be a "next" tumult, or is one-tumult-at-a-time far enough for you to look? ;)

I never was a good chess player. One tumult at a time for me, thanks.

As a 'commercial' vendor, I feel we have this already in hand, (preventing bad matches between users/use and fonts), and are likely to start swinging it around to our advantage. I'm wondering when the 'non-commercial' vendors are going to catch up otherwise, i.e. without a standard?

What is a 'non-commercial' vendor and where can I find one?

kentlew's picture

Ethan —

I think David is interested in having as much information and guidance as possible about what a font is intended and designed for — legal and typographical, equally — embedded in the font itself (i.e., self-contained, it goes everywhere with it), so that Ignorance is Never an Excuse, legally or typographically.

People will still do what they do.

From everything I’ve ever heard from David in this regard, enforcement is not necessarily a goal or, at least, is a completely separate issue. So, as far as a FB font-sniffing bot is concerned, you are wrong, I believe.

How all this data is then used remains to be seen. Who knows what might be possible once its in there?

Simple kinds of questions frequently asked here on Typophile — like “Is this font good for ____?”,“What version should I use for ____?”, “Am I allowed to do ____ with this font?” — could simply be directed to the font itself.

Christopher Slye's picture

Meanwhile, the W3C WebFonts Working Group is considering to make access to woff metadata optional.

There is really no stopping this from happening. Just as browser makers balked at standardizing EOT -- which would have required browsers to enforce EOT's security measures -- they are not interested in a requirement to present WOFF metadata. There is a large gap between technical requirements which ensure that fonts work properly, and other (desired) features which exist to "only" enlighten users or satisfy foundry interests.

There was fairly strong pushback from browser developers over the use of the word 'should' with regard to metadata ("browsers SHOULD present users with information from metadata"). Right now it looks like it will be 'may'. It's definitely not going to be 'must'.

As some have observed, the spec has to dictate to not just desktop browsers, but any user agent, which might be a lightweight mobile UA, for example. Requiring every UA to add a UI element to expose information in WOFF metadata was not considered realistic. This is disappointing to me personally, but I understand their objections.

Despite the lack of requirement, I think all the browser developers are interested in adding this functionality. Foundries can cooperate to make metadata consistent, useful and predictable, so that browser developers will see value in adding such a feature for their users. Just because it's not required doesn't mean it won't happen.

Jack B. Nimblest Jr.'s picture

>Who are the authors and who are the end-users?

Wait a minute. First bend your arm until your hand is right near your chin. See that pointy thing half way between your hand and shoulder? That's your elbow. Now... are you sitting down?

Cheers!

Arno Enslin's picture

@ Christopher

I may misunderstand you. Do you think, that metadata would be a kind of protection? Removing (personalized) metadata from woff files is probably easier than correcting font names. Convert woff to sfnt and then sfnt to woff and the personalized information is deleted. And again, it absolutely is not the job of browser developers to care about the private needs of foundries or any other software developers. Their only job is, to develop stably, comfortable programs, that strictly follow the specifications. I remember the decade, in which Microsoft has dominated the market with its shitty IE, that violated the specifications, and I am glad, that this time has gone. Browsers are not developed with the intention, that anyone can better sell his fonts with them.

Christopher Slye's picture

Arno: No, I don't think metadata is protection. Sorry, I wasn't clear with my analogy. I only mentioned the EOT protest because in that case, as with WOFF metadata, the browser developers wanted to avoid a requirement to deal with something that will come between simply fetching and rendering a font. In EOT's case, they would have had to verify EOT's security measures or be out of compliance. In the case of WOFF metadata, they would have to add a UI element to expose it or be out of compliance.

True, the browser must follow the specifications. That's why they are trying to avoid putting something in the specification that they think makes no sense -- or that they think many user agents would ignore and cause them to be noncompliant.

aaron_carambula's picture

I'm still a believer in server-side protections, like the one Typotheque uses. I wrote an open version using a combination of php sessions and filename obfuscation to block source downloads:
http://subjectiveobject.com/2009/10/28/securing-font-face/

Ray Larabie's picture

Aaron is on the right track.

Protecting fonts from being installable in an OS will seem quaint and silly in a decade when using fonts for something other that the web will be a rarity. Install fonts on your OS? Whatever, grandpa! In the near future, nobody will even want to install a font on an OS. They'll want to hotlink them. I think that's what we should be working to prevent.

Casual font pirates (the ones wearing chinos) won't share fonts. They'll share URLs to unprotected fonts, ripped right off of style sheets: all hotlinkable. If they change the font style in their Tumblr template, they've got any font you want. Design software, being web based, will allow you to link to an URL of a font. Font pirate sites will just be lists of hotlinkable URLs.

Hosted fonts are a solution but it's not for everyone. Some people want to host the fonts themselves which I can understand. Perhaps this could be solution provided by font vendors.
Let's say . . . when you buy a font for web use, you get few days of leeway to install and test the font. A few days later you get a reminder from the font vendor that your font needs to be "web activated" if it is to comply with the EULA. You send the URL to the vendor and it automatically checks to make sure you've taken measures to prevent hotlinking*. If the font isn't activated, the vendor lets you know that embedding/linking the font on the web is a violation the EULA but they can still use the font for other purposes.

* like that Typotheque link in Aaron's post above

Arno Enslin's picture

@ Aaron

With the help of the Firefox extension "Cache Viewer" it was no problem to safe the font. I only had to change the extension of SpoofFont.php (Size is 18.136 Bytes. Font contains 46 characters.). Except from that your font was displayed as Verdana in my Firefox (my default sans serif); this means, that Firefox was unable to make use of your font.

However, I agree, that this is a better protection.

ralf h.'s picture

Server-side protection also doesn't deserve the word "protection". The fonts ARE downloaded to the client and this successful request can always easily be rebuild to do a direct download or the fonts can be taken from the cache.

Casual font pirates (the ones wearing chinos) won't share fonts. They'll share URLs to unprotected fonts,

Which doesn't work with the "Same-origin rule" in Firefox, which I hope will be included in other browsers as well. But leaving out all Firefox users, makes hot-linking kind of useless already.

I am kind of surprised this discussion comes up at the moment. We discussed all this in the last 2 years here on Typophile, including server-side protection and name table obfuscating. Now almost every day a new webfont service is announced. And they all use obfuscation. Even FSI who doesn't offer raw fonts directly, offers it via Typekit. There is no doubt that this IS the interim solution until WOFF is fully established.

Arno Enslin's picture

Even FSI who doesn't offer raw fonts directly

Are you sure? I remember a discussion on Typophile, in which someone wrote, that he had licensed a raw for web embedding from FSI. I think it was Milo. It was very expensive in comparison to Typekit, especially because the license was for the web version of the font only, as far as I remember.

However, up till now I haven’t seen a web font, that has beaten the MS system fonts with regard to legibility. Actually web font embedding is primary interesting with regard to deco fonts or if the webpages are intended for printing. In this case I would provide different CSS for different media.

Except from that the best websites I have seen were not made by typographers. In my opinion some of you overestimate the meaning of commercial webfonts for the graphical quality of websites.

This is still one of my favorite websites with regard to its style:
http://www.fishmarketing.net/

(Actually) a webfont could not really improve the site because of technical limitations.

Syndicate content Syndicate content