Re: Protecting WebFonts

lee@sq.com wrote:
> 
> > >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.
> 
> The browser will resolve these automatically -- that's no help from the
> security point of view.  However, I do suggest that in *addition* to
This is a good point. I was thinking mainly of discouraging curious
end-users from just swiping the full URL and embedding it in their own
local Web page or trying something as mundane as just FTPing directly
from the originial server. In addition, URLs of the form
"~fonts/xxx.ttf" might be resolved at the server side if ~fonts is
aliased.

> other form of encryption, the server name used to fetch the font be used as
> part of the encryption key.  In that way, if someone copies a font, they
Also a very good suggestion. With the local copy of the font encrypted
with the server name, the font becomes tied to a specific site. Even if,
thwarting all the other security we might choose to throw at it, an
end-user managed to extract the font, he still can use it.

> won't be able to use it.  If the URL was forced to be relative, or (better)
> in the same 2nd level domain as the referring document (the same algorithm
> that Netscape uses for cookies woul dbe appropriate), you would not be able
> to point your style sheet at a font that someone else had paid for.
Exactly my point.

> 
> > >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.
> 
> I agree with this.  By itself, it is easily circumvented, but in conjunction
> with the simple additional encryption I suggested, this would prevent
> `casual piracy'.
> 
> > >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).
> Again, if the font is encrypted in a way that involves its URL, as well
> as the OpenType wrapper's encryption, the browser can simply store the
> (insecure) byte stream it fetched over the network.
> 
> >>  When the browser retrieves a
> > >SECURE font, it should use the SSL security mechanisms
> Well, then people in a corporate environment using a firewall probably can't
> see the font at all.  Worse, SSL isn't in all browsers, and there are
Actually, I think this has a positive for people in a corporate site
behind the firewall. The company will probably want to do internal
publishing, using site licensed fonts (possibly custom designed) which
they don't want to get loose. The people behind the firewall could get
the fonts from the document server behind the wall, people outside
can't. It works both ways.

If you are using a browser without SSL, you simply wouldn't see the
secure font. No worse than if the browser didn't implement the font
reference mechanism.

> problems with exporting SSL-aware code from the USA.  However, you could
> simply use an SSL URL to do this; no attribute is needed.
My idea was, that if you really wanted to secure the *transmission*
(i.e. protect it from packet sniffers, etc.) of the font (or any other
data, for that matter) you would take the pains to put your documents on
a secure server. The attribute was merely to inform the browser that it
had better be prepared to talk to a secure server.

[small snip]

> Lee
> 
> --
> Liam Quin, SoftQuad Inc    | lq-text freely available Unix text retrieval
> lee@sq.com +1 416 239 4801 | FAQs: Metafont fonts, OPEN LOOK UI, OpenWindows
> SGML: http://www.sq.com/   |`Consider yourself... one of the family...
> The barefoot programmer    | consider yourself... At Home!' [the Artful Dodger]

 
====================================================================
 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 16:47:05 UTC