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 >
Received on Thursday, 30 June 2011 16:09:59 UTC