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

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

> ----- Original Message -----
>> Is there really any significant benefit in hiding the true
>> information?
> It's a matter of taste or a political question, but some people do care about anonymity and/or privacy and will frown if WebGL does poorly in this respect.

If users or browser vendors feel that this divulges too much
information, they can quite simply put WebGL content under a per-site
whitelist as popups and cookies are now.

>> For application authors, there is immense value to be had from being
>> able to determine which card and drivers the user has - both at run
>> time
>> (so the application can work around bugs)
> It seems to me that we can realistically aim for good enough WebGL implementations that this shouldn't be needed. I would be very interested in the list of graphics-card-specific things that you need to do on Minefield, I would try to handle these as bugs in our implementation.

With at least 4 parties (webdev, browser vendor, card driver vendor,
operating system) involved in providing a seamless 3-d web experience,
there will always be bugs and incompatibilities. Yes, the WebGL
implementation is the critical multi-platform abstraction that should
hide these issues but limiting the information available to
application developers is the wrong place to enforce the abstraction
for pragmatic reasons. Well-written applications won't use card
sniffing unless absolutely necessary. Card sniffing has a clear
portability downside that most web devs are aware of because of user
agent sniffing.

>> and in order to provide more
>> accurate feedback when someone emails you to say "I just get a blank
>> screen" - and then has no clue as to what card and driver they really
>> have...making any chance of diagnosis almost zero.
> There are better ways in which users can easily get such information. In Firefox's case, tell them to go to about:support, that will actually give you much more detailed info. The browser is aware of the system's details, it only doesn't expose this info to web content.

A very small number of affected users will ever get that far.
Commercial applications will require wide-scale availability and
mining, e.g., site bounces for correlations with graphics vendors,
drivers, or SL implementations is incredibly valuable in diagnosing
silent failures (users for whom the application does not work but who
do not bother to submit reports).

Will Adobe Molehill provide this diagnostic facility? Quite possibly.
Make no mistake that WebGL is in competition with Flash, Silverlight,
Unity3D and the rest when application developers decide what platform
to build for. I don't want to use these proprietary platforms but if
they let my company actually diagnose problems in the field they will
have a huge leg up.

>> Unless there is some really significant security issue to be concerned
>> about here - I think we're hiding something exceedingly useful for
>> little gain.
> As I said, I see it as a privacy/anonymity issue more. How much it matters is IMHO up to the user.


>> For example: I'd like to use this in situations such as when I wanted
>> to
>> use a vertex shader texture and the underlying driver said it
>> supported
>> it, when in fact it did so by doing a total fallback to vertex shading
>> (getting me ~1Hz frame rates and making it much, MUCH worse than
>> useless!).
> This sounds very annoying indeed and seems hard to avoid without graphics card sniffing. However, I am unsure that this outweighs the privacy/anonymity issue, and on a more down-to-earth, technical note, I also am scared to think that every WebGL app using this feature will have to go through the same debugging and working-around as you did! In other words, graphics card sniffing is not just a philosophical privacy issue, it's a global inefficiency issue where many web developers will have to solve the same bug.

The alternative is letting these same global devs hang out to dry
until the browser vendors figure out the browser-side fix and roll it
out. This is measured in days to weeks, hopefully. Devs need fixes in
minutes to hours -- downtime is money.

Client sniffing is always a compromise when you are trying to write
cross-platform code but it provides a way to immediately discern and
patch problems for your application. If commercial entities are
expected to build businesses on top of this standard, they need as
much control over the successful or unsuccessful deployment of their
applications as possible. Knowing that 5% of your userbase cannot use
your application is much worse than knowing that 5% of your userbase
cannot use your application and they are all running Intel graphics


David Sheets
Ashima Arts

> Cheers,
> Benoit
>> Certainly, we could hope that such situations should never
>> arise - or that we should treat them as driver bugs - but as a
>> practical
>> matter, developers need all the help they can get and these strings
>> are
>> really useful back-stops.
>> -- Steve
>> On 11/29/2010 09:07 AM, Benoit Jacob wrote:
>> > Hi,
>> >
>> > (just comments, you can skip reading if your time is precious)
>> >
>> > In Mozilla's implementation, we decided to just return "Mozilla" for
>> > the VENDOR and RENDERER strings. For the VERSION strings, we only
>> > put the text required by the WebGL spec. Unfortunately I *guess*
>> > that a motivated attacker could still probably get much of that
>> > information by examining the result of WebGL rendering.
>> >
>> > I'm just interesting in your thoughts if you have any on the
>> > subject, especially if you think that there's anything more that can
>> > be done to prevent graphics card identification.
>> >
>> > My main concern about graphics card / driver identification is that
>> > it gives away many bits of user-identifying info, partly disabling
>> > anonymity. I'm not so much concerned about targeted attacks on
>> > drivers, as an attacker could just blindly try a set of common
>> > attacks anyway.
>> >
>> > 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:

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: