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

Re: [Public WebGL] about the VENDOR, RENDERER, and VERSION strings

On Nov 30, 2010, at 12:10 PM, Benoit Jacob wrote:

> ----- Original Message -----
>>> ----- Original Message -----
>>>> If we have to do something - I'd prefer a simple check-box in
>>>> Preferences/Privacy saying:
>>>> [ ] Hide graphics card/driver details from online applications.
>>>> (WARNING: May significantly degrade graphics performance)
>>> I would essentially be OK with this, provided that the default is to
>>> hide.
>> I was going to say the opposite. After all, aren't Cookies and
>> JavaScript
>> both enabled by default...this is a similar problem.
> Cookies can be removed. And in private browsing mode, content can't access them.
> Javascript can only become privacy-sensitive if we allow it to, which is exactly what we're discussing here!
> I think I won't write to any firefox list for now, instead I'll just say as I wrote in a previous email and wait for, say, 1 year to see if webgl apps are actually using the RENDERER/VERSION strings (since WebKit is giving this information). In 1 year, we'll have more concrete information to base decisions on, and it'll still be time to get things right for 2015 ;-)

The problem with exposing RENDERER/VERSION strings "temporarily" is that historically people have made bizarre inferences based on the existence of single pieces of information.  This leads to the needing to be around forever.

As a few examples:
  * if window.layers exists you are netscape 4
  * if document.all exists you are IE (webkit has magic for document.all so that if you try to object detect we'll lie and say it's not present, but is present should people blindly use it anyway...)
  * if the useragent string contains "4." you are netscape 4 (the safari 4.x series used 4_x_y in the useragent to prevent site breakage)

These are simply a few off the top of my head, no doubt firefox and opera people will have similar stories.

Exposing RENDERER/VERSION flags has the potential to be yet another property that people may start using to distinguish behaviour (that's why i'm opposed to having browser, etc info in the strings).  The net effect is that in time it may become necessary to expose for everyone to expose the properties simply to ensure they aren't artificially blocked from some content.

For these reason I don't believe we should ever take an "expose this and see if it's used a lot" as a mechanism for determining API - it's effectively the same as saying "add this api" as once present there's a reasonably high likelihood that the API can never be removed.

Anyway, to clarify my position: I'm not opposed to RENDERER and VERSION properties, I don't fairly heavily convinced in either direction.  Some points i'd like to make if it's decided that these properties should be present:
*  The RENDERER/VERSION/SHADING_LANGUAGE/etc properties should not include browser info - eg. shading language should simply be "WebGL 1.0 GLSL" or some such (i recognise that the real string is GL ES GLSL, but i figured that given the restrictions placed on the shader language beyond ES we probably want to call out WebGL)
*  Privacy is not just about user tracking - it is also about user categorization; If you're told the exact details of the GPU you could reasonably easily categorize the user into budget vs. middle vs. enthusiast user and target ads based on that.  You can infer some of that info indirectly (timing attacks, etc) but it becomes less accurate eg. is it a new midrange card or last years top of the line...
* Finally, history has shown that when you give developers descriptions of a system as a string rather than simply exposing the API to do a certain thing they tend to do very strange and incomplete tests and then infer everything else from that which leads to substantial pain later on (look at the average browser's user agent string to get an idea).


> Cheers,
> Benoit
> -----------------------------------------------------------
> 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:

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: