W3C home > Mailing lists > Public > public-gpu@w3.org > August 2019

Re: Extension support: maybe not a binary yes/no

From: DevSH Graphics Programming on Gmail <devsh.graphicsprogramming@gmail.com>
Date: Thu, 15 Aug 2019 11:19:31 +0100
To: "Jasper St. Pierre" <jstpierre@mecheye.net>, public-gpu@w3.org
Message-ID: <d9cead1e-6688-60ba-d529-f06eaccef0a5@gmail.com>
If we can spoof GPU and Driver/Vendor strings for privacy concerns, we
should also be able to spoof extension reports.

What I mean that a browser should be able to report extensions as not
available if GPU has bugs or user wanting to protect themselves from
fingerprinting.

Because in the end it won't help fingerprinting much if GPU names, or
architecture tags, etc. can be spoofed but the extension list either
exactly mirrors GPU caps or is just all "NO" in privacy mode.

It could be useful to advertise a random list of enabled extensions.

On 14/08/2019 16:31, Jasper St. Pierre wrote:
> There's plenty of half-working drivers out there -- the functionality is
> there, but not working exactly as expected. In this case, the extension
> still provides helpful functionality, but driver-specific workarounds
> are required. I've encountered plenty of driver-specific issues just
> through WebGL alone, and this is after ANGLE patches quite a few things
> up. That said, I don't see much benefit in a "suspicious" answer.
> Browsers can't be expected to keep its list of "yes" vs. "suspicious" up
> to date, so application code will probably also necessitate the same
> driver version checks to enable the workarounds for both a "yes" and a
> "suspicious".
> 
> On Wed, Aug 14, 2019 at 8:26 AM Myles C. Maxfield <mmaxfield@apple.com
> <mailto:mmaxfield@apple.com>> wrote:
> 
> 
> 
>>     On Aug 14, 2019, at 5:53 AM, Kevin Rogovin
>>     <kevinrogovin@invisionapp.com
>>     <mailto:kevinrogovin@invisionapp.com>> wrote:
>>
>>     
>>     Hi,
>>
>>      On the discussion on Github on dual source
>>     blending, https://github.com/gpuweb/gpuweb/issues/391, it was
>>     brought up that some hardware declared support but it was buggy on
>>     some hardware. This led me to a more general thinking on
>>     extensions. There are other cases where a driver advertises an
>>     extension but it does not work correctly and the only way to know
>>     is to either run the test oneself or examine the GPU vendor and
>>     driver string (indeed SKIA has some of this). The thought is that
>>     a browser could provide information if it considers an extension,
>>     though advertised by the driver, it may not work always. So the
>>     extension query mechanism would have three different possible
>>     results: "yes", "no" or "yes, but the browser is suspicious of the
>>     driver's support".
> 
>     An extension that doesn’t work is hardly an extension at all.
> 
>     Under which circumstances would a browser advertise an extension as
>     “suspicious” but not “no?”
> 
>     And, what would you expect an app to do when it encounters a
>     “suspicious” extension?
> 
>>     Given that there are so major browsers now (and even fewer
>>     web-engines), if a browser says the 3rd option, it can prod IHV's
>>     to fix the issue, since small ISV's have much smaller impact (and
>>     will need to implement work-arounds as well).
>>
>>     Comments?
>>
>>      -Kevin
> 
> 
> 
> -- 
>   Jasper
Received on Thursday, 15 August 2019 10:19:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:52:26 UTC