[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] about the VENDOR, RENDERER, and VERSION strings
- To: Benoit Jacob <email@example.com>
- Subject: Re: [Public WebGL] about the VENDOR, RENDERER, and VERSION strings
- From: "Mo, Zhenyao" <firstname.lastname@example.org>
- Date: Mon, 29 Nov 2010 09:09:37 -0800
- Cc: Steve Baker <email@example.com>, public webgl <firstname.lastname@example.org>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KfGZPsHBRM1jtOz/LCrHFbRlj9jQ5Tc5wtcoM61giwo=; b=dnJ5b43x2WVyxgMjkSQFQB+3Z97sIBNaxDmIZlzN0DNMNKZJF8/L4m82YOgvh/rlsV rWIge/UcseylU82c7gh9ZGis7IO0mIWopXzX7megySUxdgfs5PrXbNegW32dDFH+2xsf WsshoPKQrQzcxG4/kA4VdGTKp53TChaiZPIkA=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Vv1en+WZJTOLmCzdIJFGuB5s21oDTYvNqxvhORXCZozVTz2E525hqHFrgJUZuQp+ls LSHuxPX59BsMow2acFebtDzlI+5UiyfjfW8B+K4/H1b0JJiAl9i0Cjrp7KIpzkouDRtT SfW5UppbqyHzfB6//2m2Q2G7SoGwlQzUD6rgQ=
- In-reply-to: <1472832008.435493.1291047599809.JavaMail.email@example.com>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <4CF3CC6A.firstname.lastname@example.org> <1472832008.435493.1291047599809.JavaMail.email@example.com>
- Sender: firstname.lastname@example.org
I think exposing the vendor/driver info in WebGL or not is
insignificant and we can leave it to various implementations.
On one hand, any webgl program should not depend on the vendor/driver:
if a card should be banned or a bug need be worked around, it should
be at the WebGL implementation level, not above it.
On the other hand, hiding this info does not improve security in my
opinion: if someone knows how to use webgl to query vendor/dirver
info, he/she most likely is able to do it outside webgl.
On Mon, Nov 29, 2010 at 8:19 AM, Benoit Jacob <email@example.com> wrote:
> ----- Original Message -----
>> Is there really any significant benefit in hiding the true
> 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
>> (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
>> use a vertex shader texture and the underlying driver said it
>> 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
> 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.
>> Certainly, we could hope that such situations should never
>> arise - or that we should treat them as driver bugs - but as a
>> matter, developers need all the help they can get and these strings
>> 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 firstname.lastname@example.org.
>> > To unsubscribe, send an email to email@example.com with
>> > the following command in the body of your email:
> You are currently subscribed to firstname.lastname@example.org.
> To unsubscribe, send an email to email@example.com with
> the following command in the body of your email:
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: