[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Proposed change to WebGL spec section 4.2 (Security Origin Restrictions)

On Oct 6, 2010, at 5:06 PM, stephen white wrote:

> On 07/10/2010, at 1:07 AM, Chris Marrin wrote:
>> Because we have to. Origin restrictions are not something we can elide just because we think they are not "necessary". Security is of prime importance to many people. The news that your browser didn't respect origin restrictions would cause some companies to block the use of your browser on their site. This is a fact we have to live with.
> I'm already very nervous about the perception of security that WebGL is going to have on launch, and whether someone's going to use hardware shaders to break through to the OS. For example, reading other buffers in OpenGL, or opening a context that is not within the browser window to emulate a password request.
> Even though these problems can be cleaned up over time, it is going to be a big issue to manage public perception if the release of WebGL is shortly followed by security problems. The specific scenario that I dread is the possible need for a virtualised layer to filter out some kinds of attacks that utilise GPU chipset flaws.
> If we head down that road, then ANGLE may have to be used for GLES as well as Direct, or even drop all the way back to something that is not much faster than Flash.

You have to use a shader validator in all cases whether you're on a GLES backend or not (ANGLE is currently the most well known validator but i assume others will exist eventually) as you have to avoid exposing the many and varied interpretations of what correct behaviour is in drivers.  An safe implementation realistically should be parsing and re-serialising all shaders anyway in order to avoid exposing the drivers to parser specific bugs -- there have been many cases of people attempting to validate an input and then passing the input on to another system with a slightly different parser implementation.

These validators are simply enforcing GLES semantics on GLSL shaders, and ensuring that anything non-standard or incorrect is stopped before it reaches the drivers.  It should not have any significant performance impact unless you're repeatedly compiling are large number of shaders, in which case the problem is really in the existence of a validator...


You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: