[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.

> 
> 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.

> 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.

> 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.

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: