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

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



Thanks Ken.  I've updated the draft for the wrong name in the IDL and the issue resolved.

So I added the two extensions to the WebGL extension registry:

WEBGL_debug_renderer_info: extension #6
WEBGL_debug_shaders: extension #7

https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/extensions/WEBGL_debug_renderer_info/index.html
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/extensions/WEBGL_debug_shaders/index.html

They are ready to be implemented.  Thanks for all the feedbacks.

Mo

On Wed, Oct 12, 2011 at 2:24 PM, Kenneth Russell <kbr@google.com> wrote:
I've tentatively assigned, out of the WebGL enum block,
UNMASKED_VENDOR_WEBGL to 0x9245 and UNMASKED_RENDERER_WEBGL to 0x9246
. These will be final once they've been added to the OpenGL registry;
I've filed a request for that.

I also renamed the file to WEBGL_debug_renderer_info.html to match the
new name in the text, so the new URL is
http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_debug_renderer_info.html
.

The name in the IDL needs to be updated to WEBGL_debug_renderer_info.
Issue 1 can now be resolved.

Looks

On Tue, Oct 11, 2011 at 11:01 AM, Mo, Zhenyao <zhenyao@gmail.com> wrote:
> Thanks for all the feedbacks.  I revised the draft accordingly.
> 1) name WEBGL_debug_gpu_info to WEBGL_debug_renderer_info
> 2) name UNMASKED_VENDOR/UNMASKED_RENDERER to
> UNMASKED_VENDOR_WEBGL/UNMASKED_RENDERER_WEBGL
> 3) revised the overview of WEBGL_debug_renderer_info to explain why we need
> this extension.
> If no further feedbacks, I will add the extensions to the WebGL extension
> registry?
> Mo
>
> On Mon, Oct 10, 2011 at 4:08 PM, Kenneth Russell <kbr@google.com> wrote:
>>
>> Mo, could you also rename UNMASKED_VENDOR and UNMASKED_RENDERER to
>> UNMASKED_VENDOR_WEBGL and UNMASKED_RENDERER_WEBGL? We've been using
>> the _WEBGL suffix for new, WebGL-specific enums.
>>
>> Once that's done I can help you get values assigned to them --
>> assuming we're all in agreement.
>>
>> -Ken
>>
>> On Wed, Oct 5, 2011 at 5:07 PM, Kenneth Russell <kbr@google.com> wrote:
>> > Fair point.
>> >
>> > On Wed, Oct 5, 2011 at 5:02 PM, Ben Vanik <benvanik@google.com> wrote:
>> >>
>> >> semantics, but I'd like to second Benoit's suggestion to use 'renderer'
>> >> instead of 'gpu' - there may not always be a real GPU behind an
>> >> implementation :)
>> >>
>> >> On Wed, Oct 5, 2011 at 4:57 PM, Kenneth Russell <kbr@google.com> wrote:
>> >>>
>> >>> 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
>> >>>> -----------------------------------------------------------
>> >>>>
>> >>>
>> >>
>> >
>> >
>
>