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

Hello Brad,


________________________________

	From: Brad Kemper [mailto:brkemper.comcast@gmail.com] 
	Sent: Monday, November 10, 2008 11:40 AM
	To: Levantovsky, Vladimir
	Cc: www-style@w3.org
	Subject: Re: CSS3 @font-face / EOT Fonts - new compromise
proposal
	
	

	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.
	 
	
	
	<VL>
	 To the contrary, what I've actually suggested would benefit web
authors and service providers.  It will also benefit all visitors of
your web pages and would only to some limited extent hinder font piracy.
I realize this is probably the most font vendors can hope for.
	</VL> 
	

		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?
	

	
	<VL>
	 Just for the record, I really don't see any principal
difference between what you are asking for and EOT "root strings" (that
specify the list of sites that all belong to or used by the same
licensee), which has been so highly criticized on this list. (Please
don't kill the messenger! ;-) 
	It seems that both you and the creators of EOT had similar ideas
in mind - to allow licensee to specify a list of sites he plans to share
a resource with. I am sure we can come up with something else other then
"root strings" that would be used to allow relaxing same-origin
restrictions.
	 
	As far as access control mechanism is concerned, I hope that
there are experts on this list who would be able to answer your
question. I am interested in this answer myself - I realize that
same-origin restrictions may in some cases be burdensome, and I hope
that access control mechanism will allow to resolve this limitation.
	</VL>
	
	


		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?  
	 
	
	
	<VL>
	 I don't think OS will ever see a compressed version of the
font, since it will be decompressed by UA, hence there is no need to
update any OS or existing font engines they use.
	</VL>
	 
	 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)? 
	 
	
	
	<VL>
	It's definitely feasible to render font from RAM. And, when
applications load their own embedded fonts (regardless whether it
resides in RAM or disk cache) it should always be done in a way that
makes it available to that application only and not to other programs on
the same computer.
	 
	Regards,
	Vladimir