Re: css3-fonts: should not dictate usage policy with respect to origin

>> 2. we don't believe (and are in fact strongly opposed) to defining such  
>> rules in either WOFF or CSS3-FONTS, for the simple reason that neither  
>> of these mechanisms define a proceses for accessing font
>> resources; i.e., they have no {FETCH,ACCESS}-RESOURCE primitive;
>
> The HTTP spec has such primitives, but it doesn't look like the right  
> location for saying what applies to fonts in particular (but may not  
> apply to images or scripts or whatever else). A third spec (e.g. a Web  
> Fonts Conformance spec) would be a good place, but doesn't contain such  
> a primitive either.

If defined at the HTTP level, I don't see any issue about making this
mechanism generic enough to apply to more than fonts, and to cover all
kinds of resources. In fact, I would think that this would be one of the
primary benefit of specifying it at such a level. AnneVK's proposal
(http://annevankesteren.nl/2011/02/from-origin) is essentially that.

>> 3. we do believe that it would be useful to define the *optional* use  
>> of same-origin mechanisms in those specifications that do define
>> a {FETCH,ACCESS}-RESOURCE primitive, such as in the HTML5
>> specification, where by *optional* we mean optional at two layers:
>> (a) at the UA implementation layer, and (b) at the UA's user
>> preferences layer; that is, a UA implementer should be able to
>> decide whether or not to support same-origin, and if supported,
>> a user should be able to opt-out or, conversely, opt-in to
>> same-origin restrictions at a level of granularity determined by UA
>> implementer;
>
> I don't see how making this optional for general browsers is a good idea  
> (it may just mean no browser will implement it), and I can't think about  
> any kinds of UAs where it would make sense to make an exception. If you  
> can think of such UAs, then telling us about these would help.

It seems to me the current proposal has two goals. The first one is limit
accidental/misguided/unauthorized use of fonts hosted on one domain by
another one. I believe that this first reason is the one that has been
mentioned as explaining font creators' enthusiasm for web fonts.

While this may not please font authors, I believe that in this context, it
makes sense to consider this optional. As far as copy protection systems
go, this is fairly ineffective, since it doesn't prevent you from fetching
the font directly yourself by other means than the @font-face rule. Since
the UA is meant to work on behalf of the user, it makes little sense to
say that the UA is strictly forbidden to do things the user could do on
his own.

Another goal is to prevent information leakage that could be caused by
including fonts from an intranet into a internet webpage, and then somehow
pushing the font or information about it out of the intranet. This
probably provides stronger justification for having a mandatory mechanism,
since it is not only about acquiring the font, but also exposing it to the
script environment. But this problem is not at all unique to fonts, so a
solution that is resource type agnostic (and therefore not specified in a
font related specification) would be best.

AnneVK's proposal seems to take care of the second goal better than a font
specific rule, as it can be used on any kind of resource. With regards to
the first goal, it has the same level of expressiveness as the current
proposal. The main difference is that this is opt-in, while the current
proposal is opt-out. But I don't think that this is a significant issues,
since web servers can easily be configured to send "From-Origin: same" by
default for the relevant file types, turning the default behavior to
opt-out again.

    - Florian

Received on Monday, 20 June 2011 06:00:13 UTC