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

Re: [Public WebGL] GL_RENDERER string needed for performant apps



A long time ago, I thought the main argument for this was the following use-case:

1) Vendor XYZ has buggy drivers that can be exploited via GL
2) Malicious site uses GL_RENDERER string to guess that the person has the buggy drivers installed.
3) Malicious site uses WebGL to trigger this.
4) System compromised / crashed.

Now, 2) isn't a sure better since renderer <-> driver version isn't guaranteed, but if someone sees NVIDIA or AMD in it, they can at least ballpark it. This is probably the worst case scenario. (On the other hand, there is nothing stopping them from just doing 3) without using the GL_RENDERER string, so honestly, I'm not sure how much of a protection this really is - buggy drivers are buggy drivers, no way to get around that really.)

I'm not saying I buy this series of steps, but I don't think anyone has mentioned it yet (and if they have, I apologize o.o ).

Patrick



On Wed, Jan 15, 2014 at 9:04 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

On 1/15/14 4:02 AM, Dean Jackson wrote:

> “ooh, a fairly wealthy individual, maybe she’s interested in holidays
> to Maldives”

Or "maybe we should show them a higher price for this item".  A number of retailers are already experimenting with this sort of differential pricing based on whatever information they can get on the user....


At the moment I see some hesitation from Mozilla, but maybe due to fears of
UA sniffing rather than privacy?

What you've seen so far is me (not Mozilla officially) not being entirely unconvinced that the UA sniffing issue is as irrelevant as people seem to think it is.

The privacy situation is separate from those concerns, and as you said decided on a much higher level.  I can't speak to what our position on that is in this instance yet, though historically we've been very leery of exposing this sort of information.


-Boris

-----------------------------------------------------------
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:
unsubscribe public_webgl
-----------------------------------------------------------