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

Hello Glenn,

I would like to invite you to join WebFonts WG conference call today at

US West Coast - 13:00
US East Coast - 16:00
Central Europe - 22:00
Japan - 05:00 (next day)



Zakim telephone bridge:

     +1.617.761.6200 (Boston) or

     +33.4.26.46.79.03 (Paris) or

     +44.203.318.0479 (London)

     with conference code 3668 ("FONT")


IRC channel is #webfonts, irc://irc.w3.org:6665/webfonts


or http://irc.w3.org/?channels=webfonts


The first item on the agenda is the discussion of the formal objection from Samsung and we would very much appreciate if you could join us to provide any additional clarification for your position.

Thank you,
Vladimir


From: public-webfonts-wg-request@w3.org [mailto:public-webfonts-wg-request@w3.org] On Behalf Of Glenn Adams
Sent: Saturday, June 18, 2011 6:31 PM
To: Jonathan Kew
Cc: Tab Atkins Jr.; John Hudson; W3C Style; 3668 FONT; www-font@w3.org
Subject: Re: css3-fonts: should not dictate usage policy with respect to origin

I understand your argument, but Samsung does not agree with it:

 1.  we don't believe that mandating same-origin rules in a UA w.r.t. font loading will encourage more widespread availability or use of webfonts; in contrast, we do believe that completing WOFF and CSS3-FONTS and their rapid adoption by UA implementers in a consistent, interoperable manner will encourage more widespread use;
 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;
 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;
At this point, I believe I've stated the Samsung position clearly, and there is no need to further elaborate. I will await the WGs' resolution of this matter, and will be available for any teleconference or meeting that wishes to discuss further.

Regards,
Glenn

On Sat, Jun 18, 2011 at 4:18 PM, Jonathan Kew <jonathan@jfkew.plus.com<mailto:jonathan@jfkew.plus.com>> wrote:
On 18 Jun 2011, at 22:45, Glenn Adams wrote:
> On Sat, Jun 18, 2011 at 11:17 AM, Tab Atkins Jr. <jackalmage@gmail.com<mailto:jackalmage@gmail.com>> wrote:
>> On Fri, Jun 17, 2011 at 6:47 PM, Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>> wrote:
>> > In any case, a font file format (WOFF) and a font referencing system
>> > (@font-face) do not need to have a security story. Describing fonts (the
>> > format) and referring to them (the referencing system) does not require them
>> > to be accessed. Access is part of the UA regime, and if there is policy and
>> > controls on access, it should be defined at the UA layer, not the file
>> > format or reference layer.
>>
>> The use of fonts on the web needs these sorts of restrictions.  Do you
>> have a concrete reason why they shouldn't be specified as they are
>> (perhaps you're implementing CSS in a non-web context and don't
>> believe the restrictions are useful in your context), or are you
>> objecting on theoretical purity concerns?
>>
> First, I don't agree with your premise "that the use of fonts on the web needs these sorts of restrictions". That is a general statement that, while true in some cases, is not true in other cases.
Certainly it is not true for every use of fonts on the web. Let me try rephrasing roughly what I think Tab probably meant. I believe (and I think the Web Fonts Working Group in general agrees) that specifying these sorts of restrictions as normative behavior for user agents implementing the @font-face rule will encourage more widespread availability and use of fonts on the web, by helping to mitigate some of the fears regarding abuse of the resources that are deployed. The rapid growth of Web Fonts services and usage over the past year or so, in the light of the emerging WOFF specification (which has always been understood as associated with a same-origin restriction by the typographic community) appears to support this belief.

For those cases where the restrictions are not desired, simple mechanisms are provided to relax them. So those "other cases" that do not need restrictions are not blocked by this.

>
> Second, I am not saying "they shouldn't be specified". I'm saying they (same-origin mandate) should not be specified in WOFF or CSS3-FONTS. These are not the correct place to mandate or enforce such restrictions.
I agree that WOFF is not the most appropriate place to mandate these restrictions, and the WG has expressed its willingness to remove this from the WOFF specification if and when it is dealt with elsewhere. It seems to me that CSS3 Fonts is, however, an entirely appropriate place to address the issue: this is where @font-face is specified, and the default same-origin requirement (along with the means to relax it) is intended to be an integral part of @font-face.

JK