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

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.


On Thu, Jun 30, 2011 at 7:08 AM, John Daggett <> 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":
> > >
> > >
> >
> > 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

Received on Thursday, 30 June 2011 16:09:59 UTC