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

Well, the main point I am trying to make that *if* interoperability is truly a concern (which it is) then the desire to maintain it should prevail over all other differences. If we make this a working assumption, this may be the grounds for a fruitful collaboration that yields a solution (or a language of the spec) all of us can live with. I agree that different UAs behaving differently isn’t going to help with maintaining interoperability – this is why I am trying to find other avenues to explore.

Regards,
Vlad


From: Sylvain Galineau [mailto:sylvaing@microsoft.com]
Sent: Wednesday, June 29, 2011 4:07 PM
To: Levantovsky, Vladimir; Glenn Adams; John Daggett
Cc: John Hudson; liam@w3.org; StyleBeyondthePunchedCard; public-webfonts-wg@w3.org; www-font@w3.org; Martin J.
Subject: RE: css3-fonts: should not dictate usage policy with respect to origin

“I think our major goals are aligned.” Are they ? Glenn’s previous point implies that UAs that understand HTML4/XHTML1 could resolve @font-face one way while those that understand HTML5 may do so a different way. I’m trying to figure out how I’d tell a web author - or any user for that matter – why that’s the standard behavior they want.

From: Levantovsky, Vladimir [mailto:Vladimir.Levantovsky@MonotypeImaging.com]
Sent: Wednesday, June 29, 2011 12:59 PM
To: Glenn Adams; John Daggett
Cc: John Hudson; liam@w3.org; StyleBeyondthePunchedCard; public-webfonts-wg@w3.org; www-font@w3.org; Martin J.; Sylvain Galineau
Subject: RE: css3-fonts: should not dictate usage policy with respect to origin

Hi Glenn,

You wrote:
the primary motivation from our perspective is:

 1.  maintaining interoperability while permitting forward compatibility with HTML4/XHTML1 class UAs or any similar UA that does not already implement same origin restrictions;

I think our major goals are aligned. Interoperability is indeed one of the primary concerns, and it is believed that the specification shall provide clear and unambiguous description of the intended functionality in order to achieve the desired outcome. However, making a specific feature optional would only harm the interoperability between different implementations, it may expose users to certain already identified risks and would place an unnecessary burden on authors – in absence of guaranteed support of the API they can rely on, authors would be forced to employ hacks to achieve the same results with different UA supporting (or not supporting) the features they need.

An alternative solution may be to do what Jonathan Kew mentioned in his email – to try and identify specific environments where same origin restrictions can either be implemented with minimal efforts, or where by the very nature of implementations (e.g. a device UI that is implemented using HTML/CSS using only local resources) supporting same origin restrictions is simply not needed.

Like John Daggett said, there are very good reasons why a generic mandatory requirement to support same origin restriction makes sense for a spec that defines the behavior of @font-face implementations, but I understand that in specific conditions certain implementations may be able to  deviate from this requirement with no harm to either users or authors. Therefore, it seem reasonable to explore the possibility to have this as a mandatory requirement in top-level technology spec but relax it in a certain device profile. The opposite (having it defined as an option that is supported at a sole discretion of an implementer) would only harm the interoperability, which all of us seem to want to maintain.

Thank you,
Vlad


From: Glenn Adams [mailto:glenn@skynav.com]<mailto:[mailto:glenn@skynav.com]>
Sent: Wednesday, June 29, 2011 2:40 PM
To: John Daggett
Cc: John Hudson; Levantovsky, Vladimir; liam@w3.org<mailto:liam@w3.org>; StyleBeyondthePunchedCard; public-webfonts-wg@w3.org<mailto:public-webfonts-wg@w3.org>; www-font@w3.org<mailto:www-font@w3.org>; Martin J.; Sylvain Galineau
Subject: Re: css3-fonts: should not dictate usage policy with respect to origin

inline
On Wed, Jun 29, 2011 at 11:55 AM, John Daggett <jdaggett@mozilla.com<mailto:jdaggett@mozilla.com>> wrote:

Hi Glenn,

You write that you've proposed several different alternatives to the existing origin restriction requirement in the CSS3 Fonts specification.  However, all of these seem to be to achieve the same effect, that is to make origin restrictions on fonts loading via @font-face rules optional in one form or another, either by changing "must" clauses to "should" clauses or by spinning the requirements out to other specs.

The one thing I would like to understand is whether this is simply because of the specified origin restriction mechanism (i.e. same origin restricted by default using CORS to relax or explicit restriction via the proposed From-Origin header).  Are you objecting to either of these being required behavior or just the former of these two proposals?

either, but only the case of UAs that do not already implement same origin requirements or are not otherwise mandated to do so (e.g., mandated by HTML5); we want existing HTML4/XHTML1 category UAs that do not otherwise implement same origin to be able to normatively make use of css3-fonts and woff without bringing same origin into the picture;

i've repeated this basic objection some number of times now

I've read through your messages and I'm still not seeing a compelling reason to make the existing requirements optional, if anything recent events emphasize the compelling reasons for this requirement.  Issues like this related to security are even more important for relatively closed environments like set-top boxes where updates are infrequent.

the primary motivation from our perspective is:

 1.  maintaining interoperability while permitting forward compatibility with HTML4/XHTML1 class UAs or any similar UA that does not already implement same origin restrictions;
 secondary motivations include:

 1.  the desire to avoid introducing an asymmetry in css derived resource fetch processing, namely, where same origin applies only to fonts but to no other css derived fetch

As background, I think it would be useful to read through a description of a recent WebGL security issue below.  The context is slightly different but the issue is the same, especially what is described in the section "Cross-Domain Image Theft":

 http://www.contextis.com/resources/blog/webgl/


i will take a look at this, but it sounds like "content protection" and DRM scope to me just from the phrase "image theft"

My intention is to bring up the specific issue as to whether to make this requirement optional or not during next week's CSS WG call, I think it's best to have a formal resolution on this issue.

Regards,

John Daggett
CSS3 Fonts Editor