Re: WOFF can't be used offline (claim)

On 14/11/13 15:28, Bert Bos wrote:
> On Nov 11, 2013, at 17:47, Jonathan Kew wrote:
>
>> On 11/11/13 04:15, Chris Lilley wrote:
>>> Hello Www-font,
>>>
>>> Spotted recently:
>>>
>>> "Which means that fonts in the WOFF format, even free ones,
>>> cannot be used offline.
>>>
>>> Free fonts in the WOFF format may thus have to be converted to
>>> OpenType prior to packaging. "
>>> http://www.w3.org/Style/2013/paged-media-tasks#embedded-fonts
>>>
>>> I'm wondering how that conclusion is arrived at; not clear it is
>>> correct.
>>>
>>
>> This seems mistaken, IMO. I'm cc'ing Bert Bos, as author of that
>> document.
>
> When I studied this a few months ago, it certainly looked as if WOFF
> couldn't be used with the "file:" protocol, nor with certain other
> URL schemes.
>
> The CSS Fonts spec says that a font embedded via CSS's @font-face
> rule can only be used for a document if it and the document satisfy
> the "same origin" relation. (The exception is if the font is on an
> HTTP server and that HTTP server responds affirmatively if you ask it
> if you may use the font on a given other origin. The protocol for
> that is a bit weird: if you want to know if a document with URL
> prefix "proto://domain/" may use the font, you send the font server a
> HEAD or GET request with a special header "Origin: proto://domain"
> and the server responds with "Access-Control-Allow-Origin:
> proto://domain", which is a verbose way of saying "yes." And which
> only gives you the answer for a single origin at a time. But that
> aside.)
>
> The problem is that the IETF spec that defines "same origin" only
> allows it to be true for certain protocols, and it says that UAs may
> treat two "file:" resources either as having different origins or the
> same origin. (Although the former is noted as being more secure.)
>
> In other words, a local WOFF file cannot reliably be used for a local
> document. (And a WOFF file with certain other URL schemes, such as on
> peer-to-peer systems, with URNs instead of URLs, or with the proposed
> "ni:" URL scheme, can never be used for anything.)

Given that the CSS Fonts spec, which is where the use of same-origin 
restrictions in relation to @font-spec is specified, does NOT associate 
this specifically with the WOFF format (or with any other particular 
format), I don't know how you reach the conclusion that WOFF is any 
different from OpenType in this regard.

> But, the statement in the CSS Fonts spec about this is dubious,
> because it also appears to apply to other font formats, such as
> OpenType, which clearly *is* used locally.

Do you mean "clearly is used locally via @font-face with file URLs", or 
"used locally" in a more general sense (e.g. by putting OpenType files 
into a system's local /fonts/ directory)?

In the former case, "local" use of WOFF is no different from local use 
of OpenType. If restrictions due to @font-face's same-origin policy 
apply to one, they apply to the other.

And in the latter case, use of the font file is completely unrelated to 
@font-face's origin policy; it depends purely on what format(s) the 
local system supports.

> Different browsers seem to do different things: If you open a local
> document that embeds a local WOFF font with Firefox, the font is not
> applied.

By default, it will be applied only if it is in the same directory as 
the referring document (or, I think, a subdirectory thereof); it will 
not be applied if it comes from a parent directory, or some unrelated 
place in the filesystem.

(This restriction can be relaxed by setting the option 
security.fileuri.strict_origin_policy to false.)

This Firefox behavior applies equally to a font in .ttf or .otf format. 
It has nothing to do with the WOFF format; it is related purely to the 
interpretation of the same-origin restriction on @font-face, which is 
independent of the particular format of the font resource.

> But in Safari it is. Opera lets the user decide: it shows a
> (rather cryptic) dialog asking if you allow it to use the font.
>
> Maybe we should change the CSS Fonts spec to say that the logic of
> RFC  6454 is reversed: two resources with URLs that are
> non-hierarchical or "file:" URLs always have the *same* origin
> instead of always different. After all, the reason the RFC defaults
> to "different" is because it assumes security reasons, while CSS
> Fonts deals with copyright.
>
> And I think the spec should also limit the use of "origin" to WOFF,
> or add something like "in the absence of other mechanism." EOT, e.g.,
> already has a better system built-in

Whether EOT's embedded "root string" is a "better" system depends on 
your criteria, of course. One disadvantage, IIRC, is that it requires 
the resource to be fetched before the browser can decide whether it is 
allowed to use it.

It can also be more cumbersome for authors to deploy; e.g. restructuring 
a site to move some pages to a different domain might require modifying 
numerous binary font resources to contain a new root string.

> and there may be, e.g.,
> RDF-based solutions later, such as proposed by Creative Commons.
>
>
>> [1] http://www.w3.org/TR/WOFF/ [2]
>> http://dev.w3.org/csswg/css-fonts/#font-fetching-requirements
>
>
>
> Bert
>

Received on Thursday, 14 November 2013 15:59:19 UTC