.

Like Paul said, you can already do this with the Generator by selecting the "WebOnly" Option. I'm interested to hear your thoughts on it all. A more robust foundry service is in the works.

Whoa, finally something on the subject.

I've posted a question on the css-design google group, but, clearly, that was a wrong place to ask such a question (no replies).
http://groups.google.com/group/css-design/browse_thread/thread/d3ccff333...

Thank you guys.

So, all the mentioned stuff is already being done if I use "WebOnly" from the Fontsquirell?

Ethan, Paul, you rock.

.

Thanks for doing the research, guys. This is one to save, keep, and refer back to constantly.

Top work!

@Misha - Yes, all this is already being done in the generator.

@Elliot - Thanks!

One clarification to Paul's documentation: It is uninstallable on Windows not because the names don't match (they do and that is why the EOT works), but because the Family Name is .

I think the problem with solutions like this is that a browser or OS would be well within its rights to reject such a font. We've seen security fixes for font-based attacks from Mozilla and Apple in recent months. As part of the hardening of apps and OS's against attack, support for hack fonts may disappear in an instant - through a security fix or browser update. That's probably okay for a service like Typekit that can react instantly, but for someone hosting their own EOTs or raw fonts that would appear to be a problem.

@Simon - Agreed, it is a potential issue. But can you see any reason why they would suddenly start paying attention to the table if they aren't already?

.

@sii, Yeah, totally a legitimate concern. I've asked a friend who works on the Chrome team that developed OTS (arguably the most aggressive in-browser font security software) to look this over. My expectation is he'll give the thumbs up, but like you, I want to feel confident about it.

Since OTS was started, it has had this comment in the source, which puts me at ease:
// NAME is a required table, but we don't want anything to do with it. Thus,
// we don't bother parsing it and we just serialise an empty name table.

I'll also try to bounce this off John Daggett and Jonathan Kew of Mozilla. If you have contact with any webfonts engineers with IE, I'd love their input

>would suddenly start paying attention to the table if they aren't already?

If a documented exploit involved malformed name table entries, they may verify all entries not just the one associated with the exploit.

>If you have contact with any webfonts engineers with IE, I'd love their input

For sure, I'll point them at this thread.

Cheers, Si

I'm curious what other browsers may have been tested besides IE, Firefox and Chrome. How about Opera? Anything else? Any obscure browsers known to NOT work?

Cheers,

T

Yes, Opera Mac works fine. And I don't care honestly about obscure browsers. What is the Extensis strategy for protecting fonts?

> How about Opera? Anything else? Any obscure browsers known to NOT work?

Opera Windows and Opera Mac work with these files.

Camino doesn't yet support @font-face but since they lean heavily on Gecko, it's safe to say the experience will match Firefox.

I don't believe Epiphany or Konqueror either support @font-face yet (or really any of CSS3).

I heard back from one of the lead font engineers. He agreed with my assessment, but declined to speculate on the likelihood of Windows or IE changing their behavior.

Ethan (fontsquirrel) asked: What is the Extensis strategy for protecting fonts?

In the current "technology preview" of our service, we do a bunch of measures at different levels, including a number of things relating to font processing, along these general lines.

That being said, there's no question that this level of font crippling is more extensive than what we're currently doing. It's something we'll be looking at carefully.

Cheers,

T

@paul and all:

As you probably know, Ethan and I have discussed this a bit.
And as TP will attest, I was on a quest for the "uninstallable font name" months ago (because of the local() problem) but you and Ethan beat me to it and I appreciate and salute the hack.

My initial reaction was like Sii's - a general nervousness. There's something about it that seems frail, easily broken.

However, after mulling, the bottom line is: if the naming scheme is legit as far as the OT spec is concerned, there is no reason that I can see that it is any more vulnerable - security wise - than any other combination of entries in the name table.

(And remember, no security guy is ever, ever going to tell you that something is 100% rock solid safe. If we could predict what an attacker might come up with, there would be no ongoing need for security guys. The question is: is this less safe than any other set of naming entries? Not that I can see.)

Which leads me to a whole other line of inquiry...

All along, it has been assumed that the font delivered to the browser is easily installable in the OS. It's fair to say that this is what bothered commercial font vendors the most.
However, you've shown that's not true. The uninstallable font already exists, de facto, you've found it. And all it requires is some particular comination of entries in the name table.

All along, the focus has been on what browsers are going to to do with a font that was assumed to be installable when the real problem has always been what the OS was going to do if the user, let's say, extracted it out of the cache and tried to install it.
Success at that has always been assumed.

With all the brouhaha going on at the W3C working group over embedding bits and mandates about what browsers and WOFF conversion tools SHALL or MUST do, my question is, why not codify something like this? It already exists.

What would be objectionable about a naming scheme that makes the font uninstallable by asking that the underlying OS should, pretty please, not install a font so named?

I can't see the major players like MSFT or Apple objecting to this.

I mean, this issue was the prime impetus behind EOT and, ultimately, WOFF so why not tackle it from this angle, as well?

I dunno, just tossing out the idea. Worth thinking through, I think.

Rich

Rich: if the naming scheme is legit as far as the OT spec is concerned

There's the rub, I think. The proposed modifications of the name table are not really legit as far as the OT spec is concerned, at least as interpreted by the OS makers, which is precisely why the system will not install such fonts. This method of obfuscation is based on a current difference between the handling of web fonts and the installation of fonts on the system, and I don't see any grounds for either presuming that this difference will be maintained in its present state or that such a difference can be formalised.

.

Thanks for the summary, Paul!

Non-complicance concerns aside, would it be worth trying to corrupt the font file even further so that it can't be fixed with a font editor?
I played around a bit and managed to create a TTF that works as a web font in Safari but crashes FontLab when you try to open it; TTX doesn't work either but FontForge can open it. The problem is that it doesn't work in Chrome. It's just a quick attempt – maybe a TrueType file format wiz could devise something that works in browsers but can't be opened in editors?

Is there a way to make this more complicated, or are we now in a plateu-face looking at possible standards?

@Tim- Chrome is the kicker because they are using a library to "qualify" a font. It must pass a myriad tests before it is considered safe. Obviously whatever you did raised a red flag. That is why the NAME table at this point is where our energy is focused.

@Tomi- Ideally yes, but it is all undiscovered and untested. Likely there are few to none other alternatives right now. A font still has to behave like a font after all.

@jh

This method of obfuscation is based on a current difference between the handling of web fonts and the installation of fonts on the system, and I don't see any grounds for either presuming that this difference will be maintained in its present state or that such a difference can be formalised.

Yes, it exploits a "blind spot" in the way Windows and OSX currently recognize a font.
And there is no way to know if the blind spot will stay blind unless MSFT and Apple say it will.

But going forward, how about a simple naming convention that signals to the OS that the font should not be installed?
Be aware that commercial font producers and web designers may soon have a very common interest here.
If I break my little tush re-hinting a font, playing with the outlines, converting it, and subsetting it a certain way, I might very well want to sell the thing and not want it easily installable either.

With the acquiescence of only two parties: MSFT and Apple, things can be made simple. And I can't see what beef anybody would or could have. Forget embedding bits and EPAR tables and all that sh-t. Why couldn't a simple naming convention be adopted that asks the OS not to install the font? Making it Browser Cache-Only.
I mean, why not? Too simple?
Not much of a garden fence, but about as good as WOFF. And the two together would be about all you could hope for.

And since the internal name of the font is really irrelevant to @font-face, why not just decide on an internal keyword name that requests this non-installable treatment?
There is precedence for it with the keyword font names in the CSS 2.1 draft, too.
(cursive, serif, sans-serif, monospace - how about adding 'cache' to the list and asking user-agents to check for a match in the font's internal data and ask the platform providers to respect it?

Sii, is this nuts?

Just thinking out loud...

(Have to figure out how to get backward-compatibility, though. Can Ethan's hack be merged with such a thing? Probably.)

Rich

I doubt clients or OS’s would respect an unofficial keyword, not part of the OpenType standard. However, if the OpenType spec were rev'd to include a "do not install" bit, then I would expect that clients and OS’s would support it.

I think there would likely be push-back on standardization of such a bit. WOFF is already a “do not install” format, and depending on how clients temporarily install linked or embedded fonts they may run afoul of OS-level checks causing app compat issues. Add to this the ease of flipping the bit, it would seem to be a lot of work for little reward.

I think a more promising approach, one more likely to succeed, would be a fully spec’d permissions/electronic EULA table, where “do not install” is just one of several properties exposed.

>Why couldn't a simple naming convention be adopted that asks the OS not to install the font?

Lol.

I think a more promising approach, one more likely to succeed, would be a fully spec’d permissions/electronic EULA table, where “do not install” is just one of several properties exposed.

Promising in a way, perhaps, but I have problems with what it promises.
I'd rather it remain as is than go down that road.

Rich

> I don't see any grounds for either presuming that this difference will be maintained in its present state or that such a difference can be formalised.

Why not?

Here's a slice of the browsers in use and their marketshare:
EOT (IE 6-8): 52.7%
WOFF (FF3.5+, Chrome6): 20.8%
TTF/OTF (FF<3.5, Chrome<6, Opera): 25.4%
SVG or no support: 1.1%

So there is still a good 25% of users completely unserved by a EOT/WOFF license like FontShop's.

We still don't know for sure about Apple's plans to support WOFF. Last I heard, their lead engineer said it's easier for them to make WOFF an installable format, so that hardly solves the problem.

But now we have a format, which has protection on the level of WOFF (and even better in some cases), and works in all browsers *today*. Simon, John, David: that doesn't interest you?

>But now we have a format, which has protection on the level of WOFF (and even better in some cases),

I wouldn't describe what you've outlined as a "format", rather a set of obfuscation techniques. I find them interesting, but not that surprising - obfuscation is generally required by any font-maker considering font linking and embedding schemes, and the services (like Ascender's and Typekit) include obfuscation.

>works in all browsers *today*.

My only point was that they may not work tomorrow. In which case they'll evolve, or die.

>their lead engineer said it's easier for them to make WOFF an installable format

I think it’s up to the W3C working group to ensure that compliant apps and clients do not treat WOFF as an installable font format.

One issue with putting garbage data in a font is that it is hard to predict all the workflows which it might affect. Have you tested printing to PostScript and non-PostScript printers, and to PDF?

@davidberlow

>lol

Just a bit of giveback for all the amusement you've provided me!

(Hey, will you be at Extensis' shindig in Boston this weekend?)

rich

PI>David: that doesn't interest you?

Yes Paul it does. Thank you for the interesting material. We have adopted much like what you describe in some of our web font obfuscation technology to serve dressed naked fonts.

I'm always a bit leery about doing any messing with the font names because they are so fragile to the user, and I can't help imagining that useful file and font names with meta data support is a good goal to seek for users now.

One of the classic issues we've been facing (all composers and users of digital type), for the last 30 years, is how to keep track of fonts, (from conception to uses), mostly by file name and font name. So, e.g. for years we've been shoehorning size and foundry info into names along with family, repertoire and style info.

As I understand it, I could have to ship fonts like: FBSavageGothicBoldCondensedItalicDisplayProWebForIPadSVG18PTnot4woff.svg, and the file name could be SHTHD211.

Sii>My only point was that they may not work tomorrow. In which case they'll evolve, or die.

Simon's point is well taken, but all obfuscation techniques must evolve or die of pressure from other, arguably, overriding forces as well. The point is, however, it is the combination of obfuscation and meta data, one for the garden and one for the court, that protect fonts from most manner of ill gotten gain. It is not the font format.

Cheers!

Sii>My only point was that they may not work tomorrow. In which case they'll evolve, or die.

Sure. Though being future-proof isn't really a goal of this project. It looks pretty certain we'll have WOFF support across all browsers within 9 months.

This is stated as an interim solution, as I'd think foundries would be interested in licensing their fonts to work, securely, in 100% of supporting browsers today. :)

I'm absolutely astonished that all discussions so far are concentrated on the feasibility of this hack and nobody is making the principled argument that intentional poisoning of standard data formats is unconditionally evil, and security by obscurity really never works -- especially when the structure of the underlying format is public knowledge.

Since any software that encounters the intentionally crippled data may behave in unpredictable ways and thus open up vectors for attack, this kinds of hack -- in an environment as fragile as the web no less -- puts the data integrity and system security of the user in great danger and is therefore utterly irresponsible. As an user, I would consider this kind of technique a willful act of intrusion and endangerment -- much like rootkit DRM -- and say to anyone who employs it: Go to hell!

Some -- actually, many, as it seems -- people here need a computer security 101 lecture: The integrity of data exchanged in an open environment has -- by magnitude -- higher priority than a little bit more visual enhancement for your website.

>intentional poisoning of standard data formats is unconditionally evil

One issue with putting garbage data in a font is that it is hard to predict all the workflows which it might affect. Have you tested printing to PostScript and non-PostScript printers, and to PDF?

Still interested in an answer to Read's question.

I'm absolutely astonished that all discussions so far are concentrated on the feasibility of this hack and nobody is making the principled argument that intentional poisoning of standard data formats is unconditionally evil, and security by obscurity really never works -- especially when the structure of the underlying format is public knowledge.

You have to remember that this entire discussion is pretty much based on an inane fantasy in which intentional piracy is inevitable but users unintentionally pirate fonts by downloading web fonts and installing them without realizing that the a font license should be paid for somewhere along the way. So you really shouldn’t be surprised that the methods for preventing such a scenario are equally ridiculous.

James - Not sure I understand the tone of your post. What would you suggest? Typekit obfuscates, Fontspring obfuscates, Extensis, Ascender, Typotheque etc... To serve fonts on the web at this point has to involve a certain level of trust. None of the schemes offered by these services is unbreakable. I've easily downloaded fonts from all of the them. But if I was a "casual pirate" without the font tools, I would stumble here. Would you be comfortable with your naked fonts on the web?

I suggest you stop messing with the standard formats and keep waiting for a standard-conform web font technology that you like. Not having web fonts is not a big deal -- having intentionally corrupted data is a huge deal.

And yes, as an developer of several open source projects, I have absolutely no problem whatsoever giving away my work for free. But that's beyond the point.

I am just continually confounded at how much thought and effort goes into trying to protect web fonts from being used as system fonts given that casual pirates will probably always take the casual route and just google “fontname font rapidshare OR torrent”. I don’t entirely love the idea of naked fonts on the web. But I don’t see a need for all these hacks because I think it silly to believe that anyone who will to make the effort to pirate web fonts would pay for fonts to begin with.

henrypijames >I suggest you stop messing with the standard formats

Thank you for your comments. My advice is that you should read more. Nothing poisonous is being done to the standard itself. The parts of the standard that are used for web fonts are unmolested when compared, e.g. to the glyph standards, etc.

Type developers tread a complex maze of non-standard interpretations of the standard formats where OS developers play every hidden card they have to improve the performance of fonts on their systems, often with disregard to; the standard, the courtesy of documentation, and the web.

You could consider this kind of technique a willful act of intrusion and endangerment and tell them to go to hell, fine. We prefer to work through these difficulties like agnostics, (and I admire you for how little you know on this topic).

Cheers!

@paul irish

This is stated as an interim solution, as I'd think foundries would be interested in licensing their fonts to work, securely, in 100% of supporting browsers today.

I think you've unintentionally hit the nail on the head. I don't think font producers - in the main - are much interested in licensing their fonts to work in 100% of browsers today. I've never, ever heard any enthusiasm for providing web fonts at all. And I don't think there will be much enthusiasm for it after WOFF and EOT are ubiquitous, either.

One thing I have heard regarding licensing for the web is that "We don't yet know what business model is going to work". And that therefore, judgment should be suspended while experimentation with different models goes forward.

Yet, the one experiment I have yet to see tried by any established commercial font producer would seem to me to be the first choice/no-brainer: take a few fonts with good screen quality and offer to license them for web use and see what happens.
Until such a test marketing occurs, anybody who waxes forth about "well, we don't know what will work" is simply full of hot air IMHO.

James: I am just continually confounded at how much thought and effort goes into trying to protect web fonts from being used as system fonts given that casual pirates will probably always take the casual route and just google “fontname font rapidshare OR torrent”.

That's not my definition of 'casual piracy'. That's an intentional act to obtain a thing, not having a thing arrive on your computer because you visited a website.

But I don’t see a need for all these hacks because I think it silly to believe that anyone who will to make the effort to pirate web fonts would pay for fonts to begin with.

Exclusivity is a core value of a typeface. This is why clients pay more for exclusive use of a typeface than they do for non-exclusive use, and why retail licensors expect diminishing returns for a popular font: the more people who have a font, the less value it is perceived to have. Unlicensed use undermines this value, so whether the unlicensed user would or would not have paid for a license to begin with is irrelevant. It's especially irrelevant to my clients who are looking to use fonts on the web that are not available for licensing to other parties anyway. They are not interested in protecting sales, they are interested in protecting their investment in the exclusive value of those fonts.
___

Now, having said that, let me be clear that I'm not in favour of font obfuscation methods. The proper response to browsers that only support naked fonts for @font-face is not to support those browsers.

Henry: I suggest you stop messing with the standard formats and keep waiting for a standard-conform web font technology that you like. Not having web fonts is not a big deal -- having intentionally corrupted data is a huge deal.

I'd agree with that.

One of the things that OpenType made possible was the cleaning up of a lot of hacked, non-standard font data that had proliferated during the 8-bit years.

I don't think font producers - in the main - are much interested in licensing their fonts to work in 100% of browsers today. I've never, ever heard any enthusiasm for providing web fonts at all. And I don't think there will be much enthusiasm for it after WOFF and EOT are ubiquitous, either.

Wha?

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. Quite a while ago, Adobe joined Monotype in Microsoft to support standardization of EOT, the goal of which was to get web fonts working in all browsers.

JH> Now, having said that, let me be clear that I'm not in favour of font obfuscation methods.

Me neither it all sucks. When OT is Safest, you know what I mean.

Jh> The proper response to browsers that only support naked fonts for @font-face is not to support those browsers.

Now now. If we all felt that way about each browser maker's choice, we'd have nothing to @font-face to at all.

Cheers!

David: ...we'd have nothing to @font-face to at all.

I'd say that, at the present time, there is precious little to which to @font-face, but a lot of people pretending that there is and trying to make us think that there is some kind of pressing imperative that obliges us to do in a matter of a few months -- using whatever hacks and compromises will get us to market -- what has clearly not been a pressing imperative for more than a decade. It's surely a good thing that web type is finally moving, but between total inertia and running blindly off a cliff there is a lot of leeway for the kind of movement that goes places. There is going to be a cross-browser, standard web font format, and I don't see the point of compromising either principles or data to support what will quickly be, in the context of that format, non-standard legacy solutions affecting a minority of users. I see no more reason to support 100% of current browsers than I did to support 100% of word processing and page layout applications that didn't handle Unicode text or could only access variants using PUA mappings.
___

For me, web fonts present something of a novel situation. For a dozen years, I've been making a lot of fonts that in one way or another wouldn't work in current software. I'd make them, ship them, and wait for the applications to support the features. Sometimes I took the long road, and had to propose characters to Unicode, get them approved and published in the standard, and wait for them to be supported in software before the font would work.

So it's quite amusing to be looking at a situation in which software makers have invented a web served font mechanism for which there are almost no fonts.

Slightly off topic @John: I’ve seen way too many fonts designed with zero attention to how they behave in MS Office! That’s a definite dealbreaker for identities, at least if someone are going to use the fonts inhouse.

This thread really makes me chuckle. Thanks guys.

FWIW John Daggett (editor of the CSS3 Fonts spec) and font maestro at Mozilla gave his feedback on the details above:

Yeah, that should work fine I think. I would try printing under OSX, since that's where swizzling the PS name might matter. If the FF code changes in the future it will probably change towards the Chrome way of doing things, namely dropping the name table altogether so that we avoid all the nonsense associated with it on Windows.

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

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. :)

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.

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. :)

@johnhudson

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

> 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? ;-)

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

T

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.

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

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.

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.

FontSquirrel

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

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

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

What's the relevance of this comparison?

>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.

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.

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.

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.

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

Some people would also put a lock on the gate.

@ 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.

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.

@ 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?)

>...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!

@ "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.

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

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.

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.

@ 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.

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.

@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

>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!

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

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

Nice Craig. You made me laugh out loud.

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.

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.

@ 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;
}

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.) :-)

>...(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!

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?

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.

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

I think this is a bad idea.

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.

>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!

@ 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.

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.

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/

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

@ 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.

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.

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.

Arno:
You are against everything and for nothing. How boring.

@ Tim

You are against everything and for nothing.

I don’t know, from what you conclude that. I am for a free web – a web with almost no control, for browsers that strictly follow the specifications, for OpenSource, for the CSS Zen Garden. For me the web is not primary a market place. I am interested in a web, that becomes attractive by private sites, investigative journalist, Wikileaks. If the web becomes more attractive, because private sites use commercial fonts without a license, yes, then I am even for font piracy. I am against piracy only in cases, in which pirates earn money in any way (with the pieces of work or with sales of the prey). I am against Steve Jobs, against the government of my country, for honey melons, for Mario Feliciano, for Honduran cigars, for Russian and Polish science fiction, for most blues – from cobalt blue to azure. And for women, that are unshaved in the intimate area (I am damn conservative with regard to that!).

@arno

>In this case [printing]I would provide different CSS for different media.

I agree. On today's web, print style sheets are a rarity. But for those sites that feature certain kinds of content I believe that will change. And web fonts are a big step towards making that an attractive proposition. I mean, there's just so much Georgia and Times you can stand.
My belief: the mix of HTML/CSS/JavaScript that powers the web will become the primary "desktop publishing" platform as well. Economics will drive it. There is simply no reason to spend the money printing and warehousing a print edition when the print edition can be contained within the "screen edition" and printed as needed by both the publisher OR the reader.

>(Actually) a webfont could not really improve the site because of technical limitations. [http://www.fishmarketing.net]

Untrue - IMHO. They are using background image replacement for headings. It's a pain in the ass compared to using a font. The text is unselectable by the user. And it can create accessibility and search issues. (But I admit, I'm not up on the latest about those two.) Any way you slice it, using images for text is a hack and I'll be glad to see it go.

@ray

>Protecting fonts from being installable in an OS will seem quaint and
>silly in a decade when using fonts for something other than
>the web will be a rarity.

Yup.

@ Richard

In case of the website fishmarekting and many of the styles for the CSS Zen Garden a web font could not much improve the impression, that you get from the site. (In case of fishmarketing the letters on the book, the hatchet and the label at the bottom right could not be replaced by a web font.) In all cases, in which letters are really fused with images, web fonts cannot replace image-replacement. Additionally you cannot create the same effects with CSS as with Photoshop. With regard to headlines in a linear design I agree. And if the hinting of body text webfonts is on the same level as the hinting of some of the MS system fonts, other fonts than the system fonts are useful for body text. But in case of the following site the webfont is not an improvement in my opinion: "http://www.engstfeld-weiss.de/". It is just the other way around in case of that site. Except from the font, that does not really look good in body text on screen, the site is ordinary and boring.

With regard to Javascript: I try to avoid it.

@ralf
Thanks, I didn't know about the same origin rule in Firefox.

I'm still concerned hotlinking. I'm not concerned about a few fonts being hotlinkable. I'm concerned about what will happen after a decade of font linking with no protection. Unless it's actually illegal to make a browser that forbids hotlinking, browsers and other apps will eventually display hotlinked fonts. No?

.

Ray, I think hotlinking prevention is one of the smallest problems in this area of webfont protection. It is very easy to achieve this on the server side, and it is already widely practiced for images.

Ray, Tim is right. Hotlinking is so 1990's. It is bad for leechers -- who knows when the resource will be cut off? It is bad for the leechees as it sucks up their bandwidth. Leechers are easily caught and with a simple htaccess change you can shut it off. Nobody tolerates hotlinking as it amounts to stealing.

I was already thinking about font hotlinking pranks. Imagine what you could do with ligatures - changing the leecher's words!

@typodermic
>Thanks, I didn't know about the same origin rule in Firefox.

+1 to what fontsquirrel and Tim Ahrens said on this.
Also, Firefox defends its same-origin restrictions as a matter of security. And it's running code. As long as even one major browser restricts in this way, hot-linking is severely hampered.
If I had to bet, I think CORS will make it into the final W3C Fonts spec. At the least, it will be a "browsers may" kind of wording and FF will stick with its current policy, for sure.

rich

I've done a hotlinking prank, long time ago, when someone was basically linking to all the graphics on fonthead.com. I seem to remember changing everything to really hot pink. Not surprisingly, they stopped.

@arno

All of what you say about the fishmarketing site is true. If oversimplified in spots.
Web design is still largely about Photoshop and making things "pretty". And the site is very pretty. A digital advertising brochure. (At least the home page.)
But I would ask, "Does it make smart use of the web as a medium?" What does the site look like on a mobile browser? What does it look like on an iPad? Whereas ten years ago it was different browsers that drove web designers crazy, now it's different devices and screen sizes.
We could go on and on about this stuff. One good thing is that a lot of CSS3 is about getting rid of the need for slapping what amounts to a comp with bits of html text positioned on top and calling it a web page.
I just got back from a web design conference and one speaker showed a page that used some of the advanced CSS3 features of Safari and it was great, really. The text looked as good as anything you could cook up in Photoshop and it was just plain HTML text and CSS. And Photoshop isn't going to help you with animations. I wasn't aware how advanced Safari had become.

rich

@ Richard

Yes, the fishmarketing site is unflexible. It is a business card.

I don’t know the advanced CSS3 features of Safari, because I had uninstalled it a while ago. Safari was storing its whole setup program with each update and without removing the old setups. And I did not like the rendering engine. So I did not use it for surfing, but for testing my webpages only. But it never was necessary to correct anything in my CSS for Safari, because Safari did make use of it correctly; and therefore I limited my checks to Firefox (my favorite browser), IE and Opera.

I agree with you regarding to the theoretical possibilities, that you have with web fonts. But actually I am uncontended with the quality of most web fonts in body text sizes. Having a web font for body text, would be much more important for me, because with an embedded font you can better control line height, length and font size. But why not to embed Georgia, Verdana or Trebuchet MS? Actually not the new web fonts are interesting for me, but the possibility to embed system fonts. Although it is absurd in my opinion, if a private person, that does not sell anything in the web, shall license one of the MS system fonts. I assume, it is not allowed to embed a MS system font without a special license.

The text looked as good as anything you could cook up in Photoshop

But probably only, if the text is not fused with an image.

@arno
>But actually I am uncontented with the quality of most web fonts in body text sizes.

Me too. But let's face it - there's just so many ways you can render a lowercase "a" at 12px. There are just so many pixels and sub pixels you have to work with. It's like designing icons.
I've been scoffed at (yes, scoffed!) for suggesting that a lot would be accomplished if the MS Cleartype fonts would become ubiquitous either through licensing by Apple or by MSFT magnanimously making them available freely through @font-face.
I'm not holding my breath waiting for either to happen.

However, I'm confident that the dozen or so basic body text fonts that are needed will appear. It's just a matter of time now. Before @font-face, you could make them, but how would you distribute them? That's what's changed.

rich

>I've been scoffed at [...] for suggesting that [...] if the MS Cleartype fonts would become ubiquitous[...]

Well, today there are scoff laws in effect so I'll tell you the truth. I have heard the pleas for text faces and responded as you'll soon see. Meanwhile... the CT collection is a fine group of fonts. But, in order for a font to actually work as text on "the web" it MUST be Sized and Hinted just right. Anyone with the CT collection and Verdana on the same computer can prove this for themselves.

Cheers!

@Ralf, serverside protection is protection like a condom: not foolproof, but better than nothing. Protection is not defined as absolute, unequivocally guaranteed security. That doesn't exist on earth, and certainly not on a computer.

@Arno, you're right, it is hackable, but does require effort and know-how, can be made more difficult with obscure naming, and it voids hot-linking. What version of FireFox are you using? This works for mine (3.6.3) and in Windows, too.
– update: I actually hadn't added the bit for no-cache, should be even stronger now.

Legitimate accessibility is actually the best way to fight piracy. Great fonts available at an aggressive price point (ref. Steve Jobs) through a dead simple interface makes hacking unappealing/difficult/useless. It's a big web, go for volume, make your money, piracy won't matter as much. The goal should be to make legally licensing fonts for the web easier than hacking a site and cobbling together the bits.

If the only way someone can use a good font online is to use it outside of license, it will be done illegally or another font will be used, and foundries will lose that potential money. I'm glad to see so many good services attempting to take on the challenge, I hope more foundries make their work available, right now it's actually a competitive advantage.

The first site (I don’t no many), from which I am impressed with regard to the use of a webfont for body text (although this does not mean, that it is very legible, but only surprisingly legible considering the background color): "http://blog.fefe.de/?css=ascii.css"

It all makes sense! @ff sole purpose is to bring the Amiga back to life. :-)

As I had prognosticated: Your violations of the specs were no hurdle. Meanwhile there are many fonts floating around the web, that were ripped from Typekit. With corrected name table! And during the correction of the name table some of the fonts were probably damaged in a way, that sullies your reputation, because there are many people, that just want to test fonts, before they license them. And if a font does not work as expected, they don’t know, whether the designer or the foundry is responsible for the bugs. Some of them may decide then, that they are better going to license another font from another foundry.

By the way, in case of webfonts, that are illegally used in the web, it is much easier to to call the owner of the website to account. So, in a few years, when more people use webfonts, you can probably earn more money, if you surf a bit in the web and send those people, that illegally use your webfonts, a dissuasiveness. From this point of view you just could provide your webfonts for test purposes with the AIM, that they are illegally used. In other words: It may be, that you earn more money, if you do the contraction of that, what you actually are doing.

If I point my browser at a web site, and the web page accesses fonts on that web site, my browser won't give me a link to download those fonts, any more than it gives me a link to download the .css style sheet for the web page.

So if @font-face refers to a font I were going to try to steal, I would need to look at the source of the web page to find the URL, and use a browser that wouldn't say "hey, this is a font, I don't handle that file type" to get it.

That's not casual or accidental piracy already, so you are dealing with people to whom it will likely be trivial to pop the font into a font editor and give it a usable name again. Hence, I can't really see this suggestion as providing much in the way of benefits as an interim solution.

The full-bore web font format where the browser reads encrypted web fonts keyed to a particular URL... is probably the only solution secure enough that fontmakers will find acceptable.

"If I point my browser at a web site, and the web page accesses fonts on that web site, my browser won't give me a link to download those fonts, any more than it gives me a link to download the .css style sheet for the web page."

Urm, that depends on your browser and in some cases what plug-ins you have installed. As has often been discussed, Safari pretty much does hand you the files on a silver platter, including the fonts! For Firefox you can get add-ons to make it do darn near anything. Chrome is headed that way as well.

Cheers,

T

I wonder at what point this all becomes old news?

1) Few web authors know how to make @font-face work.
2) By and large, the fonts provided by services or licensors don't look good.

And yet there's endless discussion about how to keep the fonts that don't look good out of the hands of the people who don't know how to use them.

It's an interesting phenomenon, really.

There is no discussion such as you suggest going on here. In fact, we are about to make more good looking fonts available, and are going to show people how to use those too.

There is no discussion such as you suggest going on here. In fact, we are about to make more good looking fonts available, and are going to show people how to use those too.
I don't know who the "we" is, but I wish all concerned much success.

And to your yorkies as well.

As I am hoping to apply the @font-face feature to my own web site - using an open-source font, so that there shouldn't be a licensing issue involved; my intention is to avoid requiring viewers of my web site to install a special font for mathematics - I did some web searching.

I found a nice tutorial at

http://www.miltonbayer.com/font-face/

And I also see why there is a problem now.

Internet Explorer supports only one font format - .eot - which is locked to a given web site, and thus which allows licensing. Fortunately for my purpose, I can download WEFT from Microsoft - and I will have to check the license terms of the open-source licenses, just in case I run afoul of a religious war.

Firefox supports .woff which also has some sort embedding site lock feature, so IE and Firefox do both have safe solutions for licensed fonts. This being like 90%, I would think the problem almost is solved.

Most browsers support .ttf and .otf fonts except for IE, which is good for my application.

Chrome used to only support .svg fonts. I knew that .svg was a vector image format, but I had never even heard of .svg fonts. There's obfuscation for you! But that's been fixed, so one only needs .svg fonts to look good on an iPhone these days.

However, unlike .eot, I see that .woff doesn't involve encryption. This won't quite be good enough, I fear. It avoids open-source browser projects being frozen out, true, but some font companies just won't license for that format for that reason.

Not sure I understand your question but EOT does not have to be bound to a URL. I has this feature but you don't have to use it.

Also, WOFF has no features to “lock” a font to use on a given URL.

T

Regarding Mobile Safari on the iPad/iPhone/iPod Touch, the newest version in iOS 4.2.1 seems to display .ttf/.otf webfonts (and not just .svg). At least my Egyptian test page now works on my iPad.

http://homepage.mac.com/thgewecke/webfontdemo.html

This is useful, since there is no way for the user to add fonts to any of these devices.

>Regarding Mobile Safari on the iPad/iPhone/iPod Touch, the newest version in iOS 4.2.1 seems to display .ttf/.otf webfonts (and not just .svg).

How about WOFF?

Cheers, Si

>How about WOFF

I think not. Can you suggest a good test page where only WOFF is used?

Here's one... http://ie.microsoft.com/testdrive/Graphics/WebFonts/Default.html

Thanks, Sii. WOFF seems definitely not supported yet.

Thanks for checking. I blame Murdoch :-) he's a bad influence of Steve.

...iOS supports the most interoperable format now. The trendiest format...not so much.

and sii, iOS is to Murdoch as IE9 is to whom? Who should we blame for IE9's ttf support?

>Who should we blame for IE9's ttf support?

If you are a supporter of raw fonts then Apple clearly gets credit for being the first company to support the effort. Hakon Lie needs to get some credit for promoting the idea.

But as the Murdoch blame was a joke, I'm goig to blame Tony Stark for IE9.

Blame IEronman hu?;) and I'm not so much a supporter of raw fonts as I am a supporter of the ttf as payload for print and web. This is a big step in both the direction of apple respecting the tt spec again, and getting hopefully on the road to Woffing Cross..

Does anybody have more info about the Tony Stark - Rupert Murdoch - Steve Jobs connection? Is it true that Peter Parker's involved, too?

That would be Spiderman, Richard :-)

Jeez, Chris, you're right! Does the Justice League Of America know about this?

Only if they are Web people :-)

Superman's gonna be pissed.

He can browse faster than a speeding bullet but not on the web ;-)

http://johndberry.com/blog/2010/12/06/web-type-at-last/