Bill Hill has posted an article about "font embedding" on the Web, pushing Microsoft's "Embedded OpenType" format as the only way to do font embedding that's acceptable to font foundries. The theme is that "font linking" as implemented by Safari (and soon Gecko and Opera) is likely to get people sued and would lead to widespread font theft, and EOT is a much better approach that is endorsed by Microsoft and other font vendors. Chris Wilson followed up.
One huge problem with Microsoft taking this position is that Silverlight does not support EOT but does support direct font linking. It is very hard to take Microsoft's EOT arguments seriously when their own Silverlight division is obviously not convinced. It is especially galling for Microsoft people to practically demand that other browsers adopt EOT, and scold Apple, while Silverlight is not mentioned. It's plain hypocrisy. We need to keep pressing Microsoft hard on this issue.
Another big problem is that EOT is oversold. It is nothing more than trivial obfuscation of the font file plus some metadata asking the client to limit the domains in which the font file can be used. EOT proponents tout its font-subsetting features, but plain OpenType font files also support subsetting. The Ascender/Microsoft advocacy site suggests "EOTs are bound to a specific web page or site", which overstates the case; it's trivial for someone to unpack an EOT to obtain an unrestricted font, or to modify the domain list, or to modify a client application to ignore the domain restrictions.
The only protection of value is the ability to prevent site A from directly linking to fonts on site B, and that can also be obtained with bare font files, simply by imposing a same-origin restriction on font linking. (Even this won't be a big deal in practice; no commercial site is going to link to fonts on a random server which could be replaced with obscene glyphs at any time!) Safari 3.1 doesn't impose such a restriction but I'm in favour of it for Gecko. (We could support Access Controls for fonts so site B could permit less restrictive linking.)
The strongest argument for supporting EOT is that font foundries will sue Web authors who serve bare font files but they won't sue EOT users. That's a weak argument, since in the absence of meaningful practical differences it boils down to "font foundries are stupid" and I hope they aren't. But if that turns out to be the case, we may end up having to support EOT. Ick.
Another thing about this discussion that bugs me is the "embedded" vs "linking" terminology. "Embedded" sounds more tightly bound to particular documents than "linking", and therefore "better" ... but of course you do link to EOT files and the difference is illusory --- especially if we have a same-origin restriction on @font-face.
Update Chris Wilson comments "[Silverlight] needs the fonts to be in a package starting with SL 2.0, and that package would need to be opened (i.e. you can’t just link to fonts on other people’s systems".
Silverlight has always imposed a same-domain restriction for font loading, and I've never claimed otherwise. As for the package requirement, in March, that wasn't true. I haven't been able to determine whether direct font linking as described in that post was removed in June's beta 2 (apparently the idea you should be able to create Silverlight apps using a text editor has fallen by the wayside), but it's not mentioned in the list of breaking changes in beta 2 (or here). So I dunno. Even if they've removed that, you can probably still use FontSource and WebClient to load a bare font file. Anyone want to experiment?
Anyway, requiring fonts to be placed in the application XAP file (which is actually just a ZIP file!) is a negligible increase in protection over the same-domain restriction Silverlight already had --- I don't see the point.