[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Proposals for two new WebGL extensions
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
>>>> -----------------------------------------------------------
>>>>
>>>
>>
>
>
-----------------------------------------------------------
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
-----------------------------------------------------------