- From: Florian Rivoal <florianr@opera.com>
- Date: Mon, 20 Jun 2011 14:59:06 +0900
- To: "Glenn Adams" <glenn@skynav.com>, Martin J. Dürst <duerst@it.aoyama.ac.jp>
- Cc: "Jonathan Kew" <jonathan@jfkew.plus.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, "John Hudson" <tiro@tiro.com>, "W3C Style" <www-style@w3.org>, "3668 FONT" <public-webfonts-wg@w3.org>, "www-font@w3.org" <www-font@w3.org>
>> 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:14 UTC