Re: WOFF without SOR?

Håkon Wium Lie wrote:

> > > The WOFF submission didn't include SOR, and adding it to
> > > the WD has been controversial.
> >
> > It was agreed very early on; the WG's charter, which Opera
> > accepted, says that the conformance specification will
> > 'reference...access policies such as same-origin and CORS'.
> 
> That's hardly the same as making it mandatory. And the next
> sentence reads:
> 
>    WOFF will be the required format for compliance, the others
>    being optional. The Working Group will decide whether to
>    make the formats and linking mechanisms normative
>    references...
> 
> So the WG isn't tied to mandating SOR; we are free to do what
> we think is best.
> 
> The WOFF specification will achieve interoperability faster if
> we make SOR a separate module.

I don't think that's quite right.  The use of WOFF with a
same-origin restriction was proposed as a better alternative to
what was being proposed as EOT Lite, namely a lightly obfuscated
font format which would be licensed such that authors would be
required to do referrer checking.  Referrer checking is an imperfect
mechanism, one that breaks down in this case when firewalls or
proxy servers strip out those headers.

I know font vendors think of these mechanisms in terms of
"protection" but I think it's much better to think of these
mechanisms in terms of authors.  An author typically puts a
resource on their server for use on their site and not for use on
other sites.  Many font vendors are only comfortable licensing
their fonts for use limited to a given site.  Without a
same-origin restriction they would require referrer checking with
all its problems.  Thus you increase work for authors and
effectively end up with a lower quality solution.

For most authors, the same-origin restriction doesn't require any
work.  They put a font on their server and don't need to worry
too much about other sites leaching that resource. That's enough
to satisfy the terms of their font license so they don't need to
futz about with server settings to do referrer checking. If an
author does want to share font resources across a set of sites,
setting the CORS headers allows them to relax the same origin
restrictions.  The common case is easy and the less common case
possible.

I think removing the same-origin restriction is just going to
make things more difficult for authors (they will be required by
font licenses to implement referrer checking) and worse for those
viewing webpages behind firewalls or proxy servers that strip out
referrer headers.  If some browsers implement a same-origin
restriction and some don't then you end up with an even bigger
hodgepodge of requirements going into font license agreements. 
Sounds like a big headache for everyone.

Regards,

John Daggett

Received on Thursday, 27 January 2011 03:18:36 UTC