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

It is understood that same-origin does nothing for IPR or CP; since they were not a goal for its use, arguing SOR is not useful because it doesn’t completely address IRP scenarios is thus a red herring.

Because distinctions between embedding and reading are increasingly problematic in practice, and because the vast majority of font EULAs require the enforcement of a same-origin restriction anyway, this default behavior is consistent with both the integrity of the platform and pragmatic author needs. If the browser can easily enforce what all authors would have to configure manually in the majority of cases (when they can do it; not everyone has access to HTTP header configuration of their server) then it is proper to standardize the smart default.
Existing browsers who do not support this behavior will of course continue loading existing content as if nothing had changed; that they do exist and will remain deployed in large numbers for some time is one of many reasons why CP or IPR are not practical goals here anyway.


From: Glenn Adams [mailto:glenn@skynav.com]
Sent: Thursday, June 30, 2011 9:09 AM
To: John Daggett
Cc: John Hudson; Vladimir Levantovsky; 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

I fail to see any relationship between the link you cite below and access to font resources, whether it be embed or read access.

There is no mechanism to allow script content to access font data, even by inference (as was used in the image theft example you cite). Further, unlike JS or OpenGL Shader code, fonts do not employ a user defined, turing complete language. I admit it can be effectively argued that TTF 'mort' and 'morx' tables define FSMs, and that a malicious font could be constructed that would put the FSM into a loop, thus potentially creating a DoS risk. Actually, the same applies to OTF 'gsub' and 'gpos', which, due to the chaining mechanism, could also be exploited to create a circular chaining loop.

However, these risks are present independently of origin processing. Other than these risks, the only use I can see for same origin in regards to fonts is the protection of font owner IPR, which is clearly in the domain of content protection (CP).

I may be missing something here, but I have seen it said here that SO on fonts helps protect end users. But all I see is very weak CP for font owners. Please explain the security risk for CO fonts on end users.

G.

On Thu, Jun 30, 2011 at 7:08 AM, John Daggett <jdaggett@mozilla.com<mailto:jdaggett@mozilla.com>> wrote:
Glenn Adams wrote:

> > 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"
You should look at this more carefully, it relates more to the security
of *users* than to the security of the underlying content. It's worth a
close study, it highlights a class of security issue that user agents
must deal with these days.  Including user agents on set-top boxes that
want to support recent W3C specifications.

John Daggett