W3C home > Mailing lists > Public > www-style@w3.org > November 2008

Re: CSS3 @font-face / EOT Fonts - new compromise proposal

From: Brad Kemper <brkemper.comcast@gmail.com>
Date: Mon, 10 Nov 2008 08:39:41 -0800
Cc: <www-style@w3.org>
Message-Id: <1104B435-A31E-4FCE-BDE1-6F7CC3551F7F@gmail.com>
To: "Levantovsky, Vladimir" <Vladimir.Levantovsky@MonotypeImaging.com>

On Nov 9, 2008, at 6:05 PM, Levantovsky, Vladimir wrote:

>  Tom Phinney wrote:
> > Commercial font vendors seem to mostly want at least these two  
> things of web fonts:
> >
> > 1) That the *font file itself* or its wrapper be marked in a way  
> that binds it to a given domain/URL. (A problem with naked fonts is  
> that none of the existing fonts in the world are so marked, so any  
> scheme that involves accepting existing unprocessed fonts without  
> such markings is in a "closing the barn door after the horse has  
> left" situation.)
> >
> > 2) That the web font file NOT work on Mac and Windows OS as a  
> regular system-level font if dropped in the system fonts folder,  
> without any other processing.
> I would like to second this - and I am speaking here on behalf of  
> three leading font vendors: Monotype Imaging, ITC and Linotype. I  
> also agree with opinions expressed on this list that whatever  
> obfuscation of XOR encryption method is used it will not guarantee  
> protection of font data against unauthorized use. However item #2  
> will just make it one step more difficult to grab a font and use is  
> "as is" and for the font industry that has suffered a lot from the  
> font piracy - it is a very important issue.

In other words, it would hinder Web authors (and implementors), but  
would do absolutely nothing to hinder piracy.

> 1) by default, font resources linked with @font-face will be  
> protected by access control same origin restrictions - this will  
> eliminate the need for root strings encoded in a font resource and  
> will prevent cross-linking of fonts by other websites that are not  
> authorized to use these resources (I would like to learn more about  
> access control to be able to convince other font vendors that this  
> will provide sufficient protection against unauthorized font linking);

Is there any way for the author to turn that off? Or to specify a list  
of sites that all belong to the same licensee or are used by the same  
licensee? For instance, if my main site is www.xyz.com, can I still  
use it with 123.xzy.com, xyz.com, and secure.xyz.com, so that I don't  
have to have 4 different fonts or have the same font load 4 times  
without caching between these domains? And what about if my "site" (in  
the larger sense) is using pages on other servers that are not part of  
my domain? Often these outsourced sections of my site allow me to have  
a custom CSS file for integration of the look and feel. How can I get  
them to use my font, without actually being able to serve it from  
their servers?

With Flash, there is a specially named XML file that specifies what  
servers are allowed to share information with the file. Could  
something similar be used to relax same-origin restrictions on font  
files?


> 2) all fonts on the web will "cross the wire" MTX-compressed. I  
> believe that making all web fonts MTX compressed would satisfy font  
> vendors request #2, and no additional obfuscation of font data would  
> be necessary.

The primary problem here is you use of the word "all". In your later  
post, you seem to indicate that it would not be all. That some fonts  
could set a bit that says it is OK to not compress them. I think that  
is important. And that if the bit is not set one way or the other,  
then it is OK to compress or not, as the author decides. I imagine  
that if this compression had wide UA support, and that the tools to  
compress were free and easy to use, then this could be workable. It  
compression could even be done at the server level.

But I don't think it would offer any protection. Do the operating  
systems need to be updated so that they can read compressed versions  
of the fonts? If so, then the obfuscation-through-compression will not  
matter, as the compressed could be used anywhere. But if not, then the  
AU decompresses the font and then what? Saves it to a cache folder in  
a form that the OS can understand? Then you are right back where you  
started, with an uncompressed file that "pirates" (aargh, matey) can  
copy. Or is it feasible to have it decompressed in RAM only, in a way  
that only makes it available to the UA and not other open programs on  
the same computer (I don't know)?
Received on Monday, 10 November 2008 16:40:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:16 GMT