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