W3C home > Mailing lists > Public > www-style@w3.org > November 2008

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

From: Aryeh Gregor <Simetrical@gmail.com>
Date: Wed, 12 Nov 2008 09:33:28 -0500
Message-ID: <7c2a12e20811120633h3b71dbecp2468bcaf9b5e985a@mail.gmail.com>
To: "Levantovsky, Vladimir" <Vladimir.Levantovsky@monotypeimaging.com>
Cc: "HÃ¥kon Wium Lie" <howcome@opera.com>, "Dave Crossland" <dave@lab6.com>, www-style@w3.org

On Wed, Nov 12, 2008 at 9:14 AM, Levantovsky, Vladimir
<Vladimir.Levantovsky@monotypeimaging.com> wrote:
> For the sake of clarity and completeness, my proposal was to replace mechanism based on root strings with the mechanism based on W3C Access Control. The original idea to use access control isn't mine, and I still need to learn more about it to be able to convince font foundries (and myself) that it will work. The major change in this approach (as I see it) is that instead of sending information about "my sites" down to the UA and asking UA to enforce it, the access control mechanism will simply prevent resource data from being served to UA if the site credentials can not be verified.

No, that's not the case.  Checking in the Access Control proposal is
still on the client (UA) side.  This is the most practical way to do
it: the server serving the font file doesn't necessarily know what
site the file is going to be used for.  It will also make it
impossible to cache the file effectively if the server must be asked
whether it can be used on any given site.  Both proposals therefore
provide metadata in the response that allow the UA to determine for
itself where it can use the font, and rely only on the UA to enforce

The difference is that in the root string proposal, the metadata is
contained in the actual font file.  Therefore, it will persist even if
users copy the font between computers.  In the HTTP access control
proposal, the metadata is contained in HTTP headers, which the server
generates dynamically.  Therefore, it will not persist if the file is
simply copied between servers.

In particular, if you host a font file that's restricted to your
domain (under the access control proposal), I can download it with my
web browser, upload it to my website, and link to it there, and it
will work fine with no special modifications.  The enforcement
mechanism is therefore weaker than in the root string proposal: in
that proposal, the font file would have to be modified with an
appropriate tool to remove the strings from the file before it would
work when uploaded to my site.  Both proposals will prevent
unauthorized *direct* linking between sites (if the author doesn't
copy the font file to his own site).

This is my understanding, anyway.  If it's wrong, I'm sure someone
will correct me.
Received on Wednesday, 12 November 2008 14:34:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:41 UTC