1133170 - Expose GL_RENDERER string

Status: RESOLVED FIXED

(Core :: Graphics: CanvasWebGL, enhancement, P2)

Description

[Martin Best (:mbest)]

Obscuring this information is doing more harm than good for intensive application.  We should consider exposing this information universally.  We should insure that we have a pref in place to restrict access for more privacy minded users or surfing in privacy mode.

https://docs.google.com/documen/d/1nrOhkbCnpNf6JSS7mY7hqyVLRIvxIVerjO8h5dkaVyI/edit

https://www.khronos.org/webgl/public-mailing-list/archives/1401/msg00010.html

https://www.khronos.org/webgl/public-mailing-list/archive/1401/threads.html#00042

Comment 1

[u480271]

What do you think, Jeff?

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I don't have a strong opinion here. As long as the privacy team signs off on this, then I'm fine too.

Comment 3

[Kelsey Gilbert [:jgilbert]]

Here are the reasons for why I believe we should do this:

* Some subset of users are having graphical issues. Exposed driver info allows cross-referencing between issue reports.

* Driver A might handle method X quickly, but a different method Y slowly. Drive B can sometimes have the inverse of this. (Not always reparable at the WebGL implementation level) Exposed driver info can allow the App to make the performant choice. 

* App developers can (and often need to) ship workarounds faster than browsers can. Exposed driver info can allow for targeting the workaround.


We do need sign-off from the privacy team, and we should make this disableable via pref. I think it would be useful to also have prefs for spoofing the returned values.

Comment 4

[Kelsey Gilbert [:jgilbert]]

Point one above is specifically from the point of view of an app developer. We naturally already get this info and do cross-referencing.

Comment 5

[Sid Stamm [:geekboy or :sstamm]]

Two of the links above don't seem to work for me (one is a 404 and the other a 402).

What data is stored in GL_RENDERER?  Is that the GPU model?  Would it surprise users that we tell sites what GPU they have?

Comment 6

[Kelsey Gilbert [:jgilbert]]

(In reply to Sid Stamm [:geekboy or :sstamm] from comment #5)
> Two of the links above don't seem to work for me (one is a 404 and the other
> a 402).

The last URL should be:
https://www.khronos.org/webgl/public-mailing-list/archives/1401/threads.html#00042

I don't know what the first was supposed to be. It might be a link to the Whitepaper Google Maps did on why they believe it is necessary.

> What data is stored in GL_RENDERER?  Is that the GPU model?
Yes.

RENDERER gives information about the driver, and VENDOR just says which vendor the driver is from.

This is the informantion exposed in about:support under "WebGL Renderer", and is separated by a "--".

For the machine I'm using right now, the "WebGL Renderer" is "Google Inc. -- ANGLE (NVIDIA GeForce GT 750M Direct3D9Ex vs_3_0 ps_3_0)". Here, "Google Inc." is the VENDOR string, and "ANGLE (NVIDIA GeForce GT 750M Direct3D9Ex vs_3_0 ps_3_0)" is the RENDERER string.

> Would it surprise users that we tell sites what GPU they have?
It really depends on the user. We don't tell sites which processor a user has, or how much RAM it has. However, which GPU you have is fairly relevant to WebGL, so it shouldn't be too surprising. (Chrome and IE both expose this info already. Firefox and Safari do not)

The analogy breaks down somewhat, because one of the core problems we have is that we can't actually test and vet all drivers we run on.

In some ways, from a Webby standpoint, this is a hack. Perhaps ideally, we'd shield the actual info from access by the app, but allow the app collect data that we could reverse and determine the cause for. We could then issue errata out-of-band of uplifting (like blocklisting?) and apps could reference the errata to determine what to work around. This is much more difficult and would require a larger investment of time on our side to maintain. 

Therefore, if we can get away with it from a privacy and security standpoint, it would be easiest to cede these responsibilities to the app developers by exposing the RENDERER string.

I should also mention that some of the reservations against exposing this have been in regards to its potential for fingerprinting users. Exposing the RENDERER string adds a bunch of bits of identifying information, making it easier to track users without their consent.

Does the privacy tradeoff sound acceptable?

Comment 7

[u480271]

Could we put control under a "door hanger"?

"This website wants access to renderer description. Allow?"

If denied, we return some dummy string like "WebGL 1.0"

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to Dan Glastonbury :djg :kamidphish from comment #7)
> Could we put control under a "door hanger"?
> 
> "This website wants access to renderer description. Allow?"
> 
> If denied, we return some dummy string like "WebGL 1.0"

Realistically few users are going to know how to respond to that. It'll just be an annoyance.

Comment 9

[Martin Best (:mbest)]

Yes, no door hanger.  This is too low level a request for that to have any real validity.  Having too many of these is already a problem.

Comment 10

[Sid Stamm [:geekboy or :sstamm]]

I'm with roc and mbest: no door hanger.  IMO, this is not worth the privacy tradeoff especially since, "from a Webby standpoint it's a hack."

Perhaps there's a way to enable a "this site looks broken, send the app more data about my configuration" feature or something that would give the app this and more information, but doing it silently and by default would regress our position on privacy.

Crazy halfway idea: is there a way to enable an app to make a mapping of problematic drivers to app settings, ship the list to the client, and let the client choose the best performance settings without transmitting driver info to the app?  This would alleviate some of the fingerprinting concerns (but not all) and would at least get some of the performance wins for problematic drivers.

Comment 11

[Martin Best (:mbest)]

Can you elaborate on the privacy trade offs.  What are they exactly.  My understanding is that this would not dramatically impact fingerprinting past where it already is today.  Why would this have a considerable impact?

This is a pretty big deal of us to not expose, I'd really like us to justify not doing this with hard data that this will reduce users privacy today considering all the other information we already expose.

Comment 12

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

It's definitely a hack, but it's one where there isn't a good alternative.  Jeff explained why pretty well in comment #6.  From the point of view of WebGL, we expect drivers to render content correctly.  For the most part, they do, especially recent ones.  However, the performance varies greatly from technique to technique.  We have no way of having a mapping of drivers/hardware to different performance pitfalls, because it's going to be highly application dependent.  And the reality is that users will run content on hardware that we have never seen (either too old or too new).  We can't guarantee that WebGL will run correctly there, and so right now the only outcome is "Firefox is broken on my system".

Every time this comes up I bring up the idea of a "somewhat trusted app" model.  We should be able to collect a bunch of permissions that are generally low-risk into a bucket and allow an application to request them all at once, or maybe a few buckets.  E.g., the "game" bucket would include unmasked WebGL renderer info, fullscreen and pointer lock permissions, storing more than 50MB of data.  We can then tailor the doorhanger to this specific use case.  I realize this isn't ideal, but asking users about every permission is a pain already.

If something like that isn't an option, then we're at a state where there's tension between what we *want* the Web platform to be (competitive with native platforms) and what we're willing to *let* it be.

Comment 13

[Doug Turner (:dougt)]

There is no serious privacy loss exposing this string.  We're already way past the point where this extra entropy will cause people to be put at any risk.

Comment 14

[Martin Best (:mbest)]

Talked this over with Doug some more just to make sure I didn't have the wrong impression.  He is of the opinion that this is a go.  I agree and we should put this into motion.

Comment 15

[Martin Best (:mbest)]

Had a conversation with Doug about this and he feels this is something we should move forward on.  I'm in agreement.  This is not a GDC blocker.

Comment 16

[Martin Best (:mbest)]

(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #12)
> It's definitely a hack, but it's one where there isn't a good alternative. 
> Jeff explained why pretty well in comment #6.  From the point of view of
> WebGL, we expect drivers to render content correctly.  For the most part,
> they do, especially recent ones.  However, the performance varies greatly
> from technique to technique.  We have no way of having a mapping of
> drivers/hardware to different performance pitfalls, because it's going to be
> highly application dependent.  And the reality is that users will run
> content on hardware that we have never seen (either too old or too new).  We
> can't guarantee that WebGL will run correctly there, and so right now the
> only outcome is "Firefox is broken on my system".
> 
> Every time this comes up I bring up the idea of a "somewhat trusted app"
> model.  We should be able to collect a bunch of permissions that are
> generally low-risk into a bucket and allow an application to request them
> all at once, or maybe a few buckets.  E.g., the "game" bucket would include
> unmasked WebGL renderer info, fullscreen and pointer lock permissions,
> storing more than 50MB of data.  We can then tailor the doorhanger to this
> specific use case.  I realize this isn't ideal, but asking users about every
> permission is a pain already.
> 
> If something like that isn't an option, then we're at a state where there's
> tension between what we *want* the Web platform to be (competitive with
> native platforms) and what we're willing to *let* it be.

This idea about asking for a package of permissions is interesting and something that is likely to come up more.  Let's take this to another bug.

Comment 17

[Andrew McCreight [:mccr8]]

(In reply to Doug Turner (:dougt) from comment #13)
> There is no serious privacy loss exposing this string.  We're already way
> past the point where this extra entropy will cause people to be put at any
> risk.

If we're really just giving up on fingerprinting (which seems to be what Chrome has done) this merits a broader discussion or declaration of this than some random WebGL bug, given the previous somewhat contentious discussion around things like navigator.cores ( https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/B6pQClqfCp4/BDTENhY9HDwJ ).

Comment 18

[Andrew McCreight [:mccr8]]

If anybody is interested, the Steam Hardware survey has information about the distribution of video hardware for their users:
  http://store.steampowered.com/hwsurvey/videocard/
As you can see, there are a ton of different buckets.  The largest is only 4.5%.  (I'm guessing, based on comment 6, that the particular GPU hardware is baked into this information.)  The general population of Firefox users would probably weighted more heavily towards Intel hardware, but still.  Presumably you could get more Firefox-specific information from crash stats.

This is in contrast to number of CPU cores, where 2 and 4 together account for 92% of all machines:
  http://store.steampowered.com/hwsurvey/cpus/

Comment 19

[Anne (:annevk)]

As implementing this requires an "Intent to ship" we can have the discussion on dev.platform.

Comment 20

[Martin Best (:mbest)]

So while the argument about the cards above does show very detailed correlation, here is what we already show just by looking at WebGL.  Not just CPUs.  How does that change your thinking?

http://www.browserleaks.com/webgl

Comment 21

[Kelsey Gilbert [:jgilbert]]

This was exposed long ago.