W3C home > Mailing lists > Public > public-webfonts-wg@w3.org > February 2011

Re: Reminder: Conference call: SOR and CORS vs. From Origin

From: Chris Lilley <chris@w3.org>
Date: Wed, 16 Feb 2011 16:57:03 +0100
Message-ID: <863316817.20110216165703@w3.org>
To: Erik van Blokland <erik@letterror.com>
CC: "Levantovsky, Vladimir" <Vladimir.Levantovsky@MonotypeImaging.com>, "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>
On Wednesday, February 16, 2011, 3:43:56 PM, Erik wrote:

EvB> On 16 feb 2011, at 02:27, Levantovsky, Vladimir wrote:

EvB> As we discussed and agreed at the last telcon, we will dedicate
EvB> our next conf. call on Feb. 16 to same-origin restriction and two
EvB> alternative ways to relax the restriction: CORS and From Origin header.

EvB> Would it be possible for someone to post a brief summary of what
EvB> the from-origin proposal is? I read through the conversation
EvB> several times, but I might be missing something. 

EvB> Who is sending which header to whom?

The we server on which the fonts are hosted is senting the header to the client (e.g. browser) that has requested the fonts as a result of a font reference in the stylesheet.

EvB> What is the default?  fiddle to deny? fiddle to allow?

Nicely put. In this proposal the default is to allow, so it is 'fiddle to deny'.

So if one is using a libre font with a permissive license *and* has unlimited bandwidth (so you are happy for anyone else in the world to link to your instance of the font from their stylesheets) then the default works for you.

If you are using a commercially licensed font which requires that you limit it to the website for which you licensed it, as most commercial webfont licenses do, then the default works against you. Which  is fine in the case where the content author also has control over the server. Its a couple of lines of Apache .htaccess (or the equivalent for other servers).

In the case where smaller companies or private individuals are using a hosting provider, then in many cases they have no way to change the server configuration. Commonly, content can be uploaded but server config changes are disallowed. This leaves such people with the following options

- pay for commercial font hosting, which makes the font available from a font hosting provider at a per-month fee dependent on page views. This does mean that over time, the number of pages with 'expired' fonts will increase.

- use only libre fonts, not commercial fonts. Nothing wrong with libre fonts, just as with commercial fonts there are good ones and bad ones, but there should be a choice. Commercial fonts can be licensed for some very competitive rates nowadays. If the licensed fonts are self hosted, there is nothing further to pay.

- use a commercial font but implement user-agent checking so that its is only served to IE9 and Frefox, with Opera and Webkit getting fallback fonts. Not an attractive option and requires server access to do user agent checking

- use a commercial font outside the terms of its license and hope no-one notices.

a solution that requires small companies and private individuals to pay per month for font hosting fees is not a good one. It discriminates against them.

EvB> Who has to do the fiddling to make it do something else than the default?

Whoever is putting the font on the server. In the case of a font hosting solution, that would be the hosting provider. In the case where fonts and stylesheets and content are all hosted together, it is the content author.

EvB> How much work has to be done to make the From Origin work? By whom?

Not that much, and for common server platforms (Apache etc) an FAQ could explain how to do it simply. The question is whether the content author is able to 

I should also note that the SOR plus CORS solution flips these plusses and minuses around. Self hosting commercial fonts becomes a case of simple upload of the fonts to your server. But if you want to share libre fonts with the world, you need to add some lines of server config.

So SOR plus CORS discriminates against people who have no server access but do have unlimited bandwidth, and who want to share libre fonts.

I consider that a much lesser evil, as people who have no server config access also tend to have bandwidth constraints (charges, sometimes punitive, for exceeding a certain monthly bandwidth) so in those cases they would more likely link to libre fonts hosted at a libre fonts host which *does* have the bandwidth (e.g. Google fonts, Open Font Library). Note that in this case there is no monthly charge 
and the libre font hosting provider does have server access. So adding the server config to make the libre fonts sharable across any website that wants to use them is not an issue there.

This is why SOR plus CORS (or plus some other technology, but with the same set of defaults) is the best option currently. The common case requires no server config, and server config is mostly confined to places where it is not a hardship, and small content providers anre not penalised by being made to pay per month for commercial font hosting.

 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups
Received on Wednesday, 16 February 2011 15:57:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:15 UTC