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

Levantovsky, Vladimir wrote:
>> 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.

DRM is not the answer to the font piracy or to any other kind of piracy.
Just make the content leagally available to customers on reasonable
price and provide usable *service* they're willing to pay for.

> 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);

Again, there's no such protection for any other content including CSS,
XML, SVG, JPEG or GIF.

> 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. 

How many web authors are currently "inadvertently using unauthorized"
images, CSS or JavaScript? Why do you think that fonts deserve special
protection? (I know, I'm repeating myself. Please, I really want to know
answer to this question...)

As you said above, there will be a standalong decompressor anyway so why
should *every* browser vendor implement/include such decompressor? Does
it *really* increase security at all?

The users of *free fonts* should not be hindered by the resctrictions of
commercial font vendors. For those users, directly linking to plain TTF
file is the easiest and simpliest method. That's the method browsers
should support in any case. That's the method that will be used for
"commercial" fonts in the real world because it will work for all plain
TTF files, commercial or not. The commercial font vendors probably do
not like  it. (All those "commerial" fonts will need to be distributed
as plain TTF files to be usable in the operating system.) Nothing
prevents the user from putting that plain file on a public web server,
either (except the copyright law, which you probably do not believe in
because you're not happy with plain TTF).

EOT does not prevent users from distributing plain TTF files on public
web servers. It only prevents using that said font on a web page easily.
Count me totally unsurprised that this DRM system would hinder usability
and would not prevent piracy.

-- 
Mikko