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

Re: [Public WebGL] Proposals for two new WebGL extensions



On Wed, Oct 5, 2011 at 4:22 PM, Benoit Jacob <bjacob@mozilla.com> wrote:

On 05/10/11 03:56 PM, Gregg Tavares (wrk) wrote:


On Wed, Oct 5, 2011 at 12:08 PM, Benoit Jacob <bjacob@mozilla.com
<mailto:bjacob@mozilla.com>> wrote:


   On 05/10/11 02:38 PM, Mo, Zhenyao wrote:

       I wrote up drafts for two possible WebGL extensions:
       WEBGL_debug_shaders
       and WEBGL_debug_gpu_info.

       https://cvs.khronos.org/svn/__repos/registry/trunk/public/__webgl/extensions/proposals/__WEBGL_debug_gpu_info.html
       <https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/extensions/proposals/WEBGL_debug_gpu_info.html>
       https://cvs.khronos.org/svn/__repos/registry/trunk/public/__webgl/extensions/proposals/__WEBGL_debug_shaders.html

       <https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/extensions/proposals/WEBGL_debug_shaders.html>

       WEBGL_debug_shaders exposes the translated shader source.
       WEBGL_debug_gpu_info exposes the unmasked VENDOR and RENDERER
       strings
       from underlying graphics driver.

       I believe these two extensions provide important information to
       WebGL
       developers.  However, as stated in the drafts, both extensions
       should
       only be available to privileged code in a browser, not the regular
       content due to user privacy concerns.


   I'm OK with the two extensions as currently drafted; just a couple
   of remarks:

     *WEBGL_debug_gpu_info might be better named
   WEBGL_debug_renderer_info (or see below,
   WEBGL_privileged_renderer___info) ? Also, it says that that info

   should not be exposed to unprivileged content, so should the WebGL
   spec also be updated to be consistent with that? Currently the WebGL
   spec does not mention the concern about these strings.

Whether to report the real RENDERER and VENDOR strings in the core WebGL API is still an active area of discussion -- or at least there have been discussions very recently on the topic. For this reason I think we should leave that spec as is for now. However, it might be worth adding some clarifying documentation to WEBGL_debug_gpu_info. Maybe modify the Overview:

WebGL implementations might mask the RENDERER and VENDOR strings of the underlying graphics driver for privacy reasons. This extension exposes new tokens to query this information in a guaranteed manner for debugging purposes.


Also, I
   wonder if PRIVILEGED would be a better word than UNMASKED, so it
   would tell in a more explicit and neutral way what the difference is
   with the current strings from the spec. Similarly, the extension
   might be better named WEBGL_privileged_renderer___info?


     * WEBGL_debug_shaders might not be a specific enough name? How
   about WEBGL_get_translated_shader___source or some such. The text

   says that this should not be exposed to unprivileged content because
   this could be used to identify the GPU. Personally, my concern is a
   bit different. I'm not that much concerned about this particular
   privacy issue as it doesn't seem to expose a lot more information
   than we already expose (through getShaderInfoLog + getParameter + UA
   string), and doesn't make it more convenient to obtain. What I'm
   more concerned with is that it exposes precisely which workarounds
   we use, so if an attacker was fuzzing our ANGLE workarounds to find
   corner cases where we miss a workaround, that could be handy.


How is that any different from today? If an attacker wants to find out
which workarounds we use, at least for Firefox and Chrome they can just
download the source and find out. Yes this makes it slightly easier,
they don't have to compile themselves and add a single printf, but it
doesn't expose anything they couldn't already get.

So that's true for the two browsers that currently ship WebGL enabled by default. How much is that something that we can rely on, as opposed to just an 'accident', I don't know. But it surely isn't my job to advocate security-by-obscurity so I won't push this point further :-)

The availability of this extension definitely makes it much easier to query the post-translation source code, and it isn't currently available to _javascript_, so I think it's safer to expose it only when explicitly enabled.

Regarding the naming convention, Ben Vanik suggested in an off-list email that we could expose more extensions with the WEBGL_debug_ prefix which may be useful in implementing tools like the WebGL Inspector. This sounds like a really good idea, so I'd vote to keep the current convention.

-Ken


Benoit




   Cheers,
   Benoit


       Comments are welcome.

       Mo



   ------------------------------__-----------------------------

   You are currently subscribed to public_webgl@khronos.org
   <mailto:public_webgl@khronos.org>.

   To unsubscribe, send an email to majordomo@khronos.org
   <mailto:majordomo@khronos.org> with

   the following command in the body of your email:
   unsubscribe public_webgl
   ------------------------------__-----------------------------




-----------------------------------------------------------
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:
unsubscribe public_webgl
-----------------------------------------------------------