Protecting WebFonts

Glen,

The recent discussions and proposals in the W3C fonts news list about
fonts on the Web have raised some very legitimate concerns about
protecting the works of font designers and type foundries in the world
of global electronic publishing.

While each of the proposals has some potential advantages, and
disadvantages, in my opinion none of the proposals - GIFs, PixelFonts,
Java App/Fonts - really addresses the issue of how to prevent the
misappropriation of fonts in already popular and well-established
formats, if they are to be used effectively on the Web. As desirable and
flexible, and gee-whiz as a new font format might prove to be,
publishers will be reluctant to give up their investments in their
current font libraries or to simply wait to do their Web-based
publishing until a new font format has been worked out and accepted by
the industry.

To bring the discussion back into the realm of font security, let me
make a proposal that focuses on securing *all* fonts, in any current or
future format, that is based on available technology and known good
encryption and authentication techniques.

1. I believe, very simply, that fonts should not be embedded on a Web
page - that is, the font data and fonts programs in any format that can
be handled directly by standard font rasterizers, like TrueType or PS
Type 1, should not become part of a Web page in any form. Not
re-encoded, not encrypted, as a block of binary data, etc. Not in any
form.
  The mechanisms used in HTML, or CSS1 to specify a font for use on the
page should specify either a URL reference to a font on the Web server,
or a set of parameters that allows the browser to match local fonts to
the desired font (you know, like Face/Family, Weight, Style or PANOSE,
or other font mapping systems), or the set of parameters that allows the
browser to synthesize a font with particular metrics, using any font
synthesis technologies they might build in (like Adobe MM, or Chamelion,
etc.) ... THAT IS, there can only be a *reference* to a font, *never*
the font itself.

2. Having a full URL for the font might tempt some less than upright net
denizens to try to get the font directly from its Web server. To prevent
the outright advertisement of the location of a font, the font URL
reference should be restricted to *only* relative URLs, not fully
qualified URLs.

3. The browser itself must enforce a policy that prevents *any* font
from being downloaded from a Web server different than the one
originating the Web page the font request is in.

4. When the browser downloads a font from a Web server and "installs" it
into the operating system (so it can take advange of the regular OS font
machinery), the browser *must* use the existing facilities for "private"
installation (both Windows and Mac have parameters for installing fonts
as private). This way, the fonts are not seen by or available to other
applications running on the same box - only the browser will be able to
use the font. For UNIX, because there is no standard font mechanisms
(except for X BDF fonts), it is likely that the browser, if it
implements font support, will have a built in connection to a
font-rasterizer or two, and it can control its use of the rasterizer
very tightly.

5. If a browser downloads a font and keeps it in its cache, the font
*must* be encrypted (with strong encryption, like RSA or PGP).

6. A Web page author should be able to specify that they want secure
_transmission_ for a font. The font reference tag(s) in HTML or CSS1
should have an optional attribute "SECURE". When the browser retrieves a
SECURE font, it should use the SSL security mechanisms, The server for a
secure font must then, of course, be a secure server.

Given these precautions, and the cooperation of browser vendors and
manufacaturers, I believe that fonts can be safely used on Web pages
without fear of casual appropriation, or even moderately determined (and
therefore *deliberate*) attempts to lift a font out of its Web page.

 
====================================================================
 Gary Ruben                             Bitstream Inc.
 Senior Software Engineer               215 First Street
 mailto:gdr@cataneo.bitstream.com       Cambridge MA 02142-1270 USA
--------------------------------------------------------------------
Bitstream does not necessarily endorse any opinions expressed here.
       (Come to think of it, you might not either. 8-o)
====================================================================

Received on Thursday, 22 August 1996 09:06:15 UTC