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

Hello WG,
 
I am Vladimir Levantovsky representing new W3C member Monotype Imaging
Inc., and I would like to thank you all for your ideas and opinions
exchanged in this discussion. I found it to be engaging and in many ways
educational - being able to see the subject of the discussion through
the eyes of web developers and UA vendors does bring a whole new
perspective to many issues.
 
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.
 
Having read the messages on this discussion thread and knowing your
concerns about various aspects of EOT submission, I would like to
propose a new alternative compromise solution for your consideration. As
you know, one of the technology components of EOT solution is the
MicroType Express (MTX) font compression
(http://www.w3.org/Submission/2008/SUBM-MTX-20080305/). My alternative
proposal consists of two items:
 
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);
 
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. 
 
Due to special features of this compression mechanism (it's been
developed with intrinsic knowledge of fonts) it creates
lossless-compressed files that, on average, produce results that are 30%
better than TTF fonts compressed using gzip. Decompression will be done
by UAs before a font is served to a font engine as a raw TTF/OTF font -
no changes would be required for any existing platform that is capable
to render TTF/OTF fonts. I do realize that standalone decompressor is
likely to be made available soon, and those who want to get their hands
on a pirated copy of a font will be able to do so. However, it would
require a conscious decision to do it, and IMHO will prevent many from
inadvertent unauthorized use of fonts. 
(I trust that web developers are very much aware about licenses and
would never use unlicensed fonts, but there are many more users on the
web and some of them might do it if we make it as easy for them as
finding a link to a raw font and copying/pasting it into a browser.)
 
Besides the obvious benefits of applying compression for fonts, such as
reduced storage space on web servers, faster download times and ability
to serve fonts on low-bandwidth connections, I believe this proposal (if
adopted) will satisfy font vendor concerns and solve all the issues
related to web development and resource use:
- compatibility with different stages of production pipeline (where
fonts used in production of web content can be compressed by CMS tools);
- caching of the web content on different servers, saving a copy of the
webpage on a local machine (since fonts will be saved compressed, along
with other resources), etc.
 
I am very much looking forward to your constructive criticism of this
proposal.
 
Thank you for your consideration,
Vladimir