RE: What constitutes protection [was: About using CORS]

> From: www-font-request@w3.org [mailto:www-font-request@w3.org] On
> Behalf Of Garrick Van Buren


> Yes. Firefox supported cross-domain before it implemented SOR.
In a released build or a nightly ?

See https://bugzilla.mozilla.org/show_bug.cgi?id=70132#c165
Also, all MDC document I've found does not mention that this was 
released without then added later. 

Be that as it may, this is now a moot point unless a lot of Firefox
users stuck to the older cross-domain release.

> This thread has already discussed a number of existing file formats
> without a similar 'protection' that frequently contain creative work
> with restrictive licensing models. There's already a space in the
> original font format for licensing info, we've talked about the WOFF
> metadata potentially including additional licensing information.
> Independent of the security issues you pointed out (that I've yet to
> fully review) - from a licensing perspective - including this sort of
> check within the format seems doubly redundant.

For arguments on whether and why fonts are not like those other creative
works, feel free to also peruse the archive.

I do not think SOR is redundant on these grounds: 
a) it's not 'within the format' itself, this is the protocol to follow 
when requesting a font cross-domain 
b) browser vendors will not parse and enforce licenses; in fact EOT's
rootstring - a real same-origin policy definition *within the format * -
was rejected for that reason (as well as other operational ones)
c) this scheme does not *prevent* fonts from being used cross-domain if
the license allows it. It only says that this won't happen *by default*.

Given that this happens to align with the default requirements of the 
vast majority of font licenses today, I'd argue it's still worth having
even if it was redundant.


> >> It is conceivable that a license exists that would be violated
> because of
> >> this recommendation.
> > It certainly is. But it is also conceivable that number of licenses -
> and
> > fonts - that are not violated by this recommendation is far higher.
> 
> Sure, and again, as you stated - licensing it outside the scope of this
> WG.

It is out of scope to the extent that font licenses do not make our
deliverable useless in the real world. I have no interest in producing
theoretical work and code that adds no value to the status quo. If
this standard conflicts with the vast majority of font licenses in such
a way that it will provide no extra choice to web authors above and
beyond the limited incompatible status quo they are burdened with today,
then my interest in implementing it will approach zero at a very high
rate. And I suspect I won't be the only one.

It's very nice to say that this is not necessary in an ideal world.
I'd rather make it work in the real world. If the theory doesn't fit,
I'm inclined to update and fix the theory instead of waiting for reality
to bend to it. 

Others see it differently, of course, and that's a perfectly fine conversation
to have as long as it is rooted in available evidence and logical reasoning.


> Problematic because some web servers are setup to gzip all assets they
> serve by default. Today, this creates unreliable results with WOFF -
> thus requiring additional configurations to reliably serve this
> specific font format.

Why does this create unreliable results with WOFF vs. say, any other format
that is already natively compressed (video, audio, images...) ?

Received on Tuesday, 4 May 2010 17:14:03 UTC