Re: FW: EOT-Lite File Format

Sorry I was gone for the weekend, guys - was visiting a winery with my
wife.  There's been enough speculation thrown around about what
authors would or wouldn't want that I probably could have been useful.
 ^_^

On Sun, Aug 2, 2009 at 2:46 PM, Sylvain Galineau<sylvaing@microsoft.com> wrote:
>>From: www-font-request@w3.org [mailto:www-font-request@w3.org] On Behalf
>>Of John Hudson
>>Sent: Saturday, August 01, 2009 10:29 PM
>>To: www-font
>>Subject: Re: FW: EOT-Lite File Format
>
>
>>The first of which 'sucks' and the second of which is not a valid part
>>of the EOTL format, this suggests to me that either the font makers
>>require something of the authors that 'sucks' -- in which case authors
>>will protest -- or it means that font makers do not require access
>>controls on the part of the author and rely on font metadata,
>>serialisation, etc. to track linking.
>
> I do respect Roc's extremely well-informed opinion but we - at least I- may
> wish to do more due diligence. It was not so long ago that arguments were leveled
> against EOT's rootstring feature on two grounds: first, that they are
> painful to manage in practice and unlikely to be used when other methods,
> while not as reliable, already exist that are used to protect other resource
> types from hot-linking and other abuse. Second, that a user agent which
> ignores such rootstrings might be circumventing access control measures
> under the DMCA. As a non-lawyer who has no way of judging the validity of
> the latter concern when - it has only been asserted by other non-lawyers so far -
> I remain confused by the apparent 180, from : rootstrings are unusable in practice,
> and ignoring them might be illegal. To: roostrings are better than the alternatives,
> it is perfectly OK to ignore them.
>
> Again, I won't dwell on the legal angle and will leave that topic to those who do
> have actual expertise in the matter. But I'd love to hear more about the alternatives
> to rootstrings for cross-domain access control purposes and the workflows involved
> so that I get a better understand of what 'sucks'.

I tried to answer this before, but apparently didn't do it well
enough, so let me cover it again.

Rootstrings suck.  That's pretty simple.  They suck, because in
practice we authors stage things on multiple servers, on multiple
domains, across multiple CDNS, etc.  Rootstrings make it difficult to
manage these and require a big "change all the fonts" action whenever
any part of this chain changes (more likely, well *after* it changes,
when somebody realizes that the fonts have stopped working).

The legal issue is also scary.  America's (ab)use of the DMCA is
frankly terrifying, and almost anything you do can be risky.
Rootstrings in EOT may very well be classified as a preventative
measure, and thus illegal to circumvent.

None of that applies, at least in full, to the proposed "rootstrings
in padding" version of EOTL.  For one, this is always going to be
essentially a *browser hack*, not a required practice.  It's something
that will be used to address specific problems in certain *legacy*
browsers, but all the modern browsers will work just fine without it.
Thus in an author's mind (like mine), it's a far different thing.
It's also essentially temporary, especially in light of the fact that
the IE division is actually *moving* these days and laying down new
code.  The percentage of people using such legacy browsers constantly
shrinks, so in a relatively short time we can completely do away with
the need for the rootstring hack at all, just as these days many of us
can completely ignore the box-model hack for IE6.  I usually take a
few minutes to make sure that my pages are *usable* in IE6, but I no
longer have to care about it looking nice.

The legal side, too, seems much changed.  I'm not a lawyer, nor do I
play one on TV, but if an EOTL spec does not mention rootstrings (or
even goes further, and explicitly acknowledges that while rootstrings
were in the version of EOT that EOTL is based on, they're now part of
'padding' and MUST be ignored) then it seems that we're pretty much in
the clear.  The only problem I see arising is if a modern EOTL
compliant client accidentally interprets an EOT file as an EOTL, and
then goes on to ignore the rootstrings that *are* intended to be
obeyed.  As long as there's a reliable way to distinguish between the
two, I think we're good.

On Sun, Aug 2, 2009 at 5:22 PM, Robert O'Callahan<robert@ocallahan.org> wrote:
> It is clear, however, that if you only have the ability to upload files to a
> Web server, but you can't configure it to the level of examining Referer
> headers, then you won't be able to use Referer checking while you could
> still use rootstrings, however painful they might be in your workflow. It is
> also well-known that many firewalls strip Referer headers so users behind
> those firewalls will never see fonts controlled by Referer checking. That is
> why I think rootstrings would more attractive to authors than Referer
> checking.
>
> I don't know of any other technique to provide the sort of access control
> that Ascender's license is asking for, for users with IE<=8.

As an author, I can support ROC's statement that Referer checking
sucks.  If you don't have fairly substantial control over your web
server, you really can't do it.  Even with such control it's a bit
annoying.  I'm sure I could do it on the Apache level, but I don't
know how - I'd end up creating a php file that checked headers and
then emitted the font data.  It'd end up sorta clumsy, with me putting
url(font.php?file=Justov.ttf) into my CSS, and that's also an easy way
to expose your entire website to attack if you're not careful (the
naive way to write it would allow an attacker to gain full read access
to your entire server).

(To be honest, I'd probably use mod_rewrite to let me link 'directly'
to fonts and have the request get rewritten into that php file.  But
that requires another step up in server control and knowledge that
authors may not have.)

I'll note, though, that I don't see any reason to reject on a null
Referer.  As ROC notes, there are plenty of legitimate reasons to
strip a Referer header, and the number of people that do it
purposefully to gain access to content they shouldn't be able to is
vanishingly small.  (Luckily most other server admins feel the same
way, as it enables me to create some personal mashups that only work
if I suppress the Referer header - I am precisely the guy that I claim
is "vanishingly small". ^_^)


In the end, though, I think all of this will be unnecessary.
Same-origin restrictions serve only to prevent cross-origin requests -
hotlinking, in other words.  As long as most of the ecosystem obeys
this, then hotlinking is essentially useless.  Fast forward to a year
or so from now, when the non-IE browsers will have implemented EOTL
support and released, and enough people have upgraded to make it worth
it to deploy EOTL files.  You put up a font.  Someone hotlinks it to
use on their own site.  What happens?  The font is completely ignored
on 30%-40% of browsers! (Assuming that userbase distribution is the
same as now.)  This is *not* acceptable on a large site, and the set
of people who won't see is unacceptable to most small techie sites
(who tend to respect non-IE users more).

Basically then the only people who will hotlink are (a) clueless, (b)
possibly IE fanboys (no real disrespect - I'm an FF fanboy), and (c)
probably small enough to ignore.  And the percentage of users for whom
the hotlinking works shrinks by the day as they move to conformant
browsers.

~TJ

~TJ

Received on Monday, 3 August 2009 14:28:44 UTC