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

So, there is no end-user risk that is being addressed here other than the
hypothetical case of violating an EULA? Is that really what all this noise
is about? Could you send me or point me at a EULA for which SOR on fonts is
relevant?

On Thu, Jun 30, 2011 at 11:59 AM, Sylvain Galineau
<sylvaing@microsoft.com>wrote:

>  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>
> 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****
>
> ** **
>