[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] about the VENDOR, RENDERER, and VERSION strings
On Tue, Nov 30, 2010 at 4:45 PM, Benoit Jacob <firstname.lastname@example.org> wrote:
>> In the case of the example I gave - I don't see how you CAN fix this
>> WebGL. There are many areas of OpenGL where this problem arises - I'm
>> going to continue to use the vertex texture example - but there are
> Have you looked at my ACCELERATION_STATUS proposal in my previous email? I had your use case in mind, and was also aware that this would be just one of many others, possibly too many for us to try to handle in the browser implementation, that's why I proposed to settle for a coarser acceleration-status detection. I realize that it wouldn't allow you to tweak your rendering as finely as you could with the RENDERER etc strings, but I argued that this should be enough. What's your opinion on this?
Steve explained in an earlier email how ACCELERATION_STATUS may not be
very useful, since there are many dimensions of hardware performance.
If we add status bits for every possible performance measure of
interest, that would end up supplying the same entropy for user
fingerprinting that you are trying to avoid by denying a meaningful
RENDER result. The other reason not to do this is that vendors will
get it wrong, like Steve described with the vertex-texture-fetch
In the end, what WebGL app developers are going to want is effectively
a fingerprint of the user's hardware, for use in setting default
graphics features. There are workarounds that don't involve RENDERER,
like we could try to fingerprint the hardware using other queries
(less reliable, more dependencies), or have each app benchmark each
user independently (slow).
My feeling is that the RENDERER string is extremely useful to WebGL
app devs, and of only slight benefit to people who want to fingerprint
users (they already have better sources of entropy as highlighted in
the EFF paper). So I hope we keep a useful RENDERER.
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: