It sounds like there are three use cases for WEBGL_debug_renderer_info:
1. Correlating GPU info with bug reports (e.g. YouTube).
2. Web content workarounds for GPU bugs.
3. Fingerprinting for user tracking.
To get #1, some of #2, and none of #3, can we just whitelist
WEBGL_debug_renderer_info for youtube.com or a couple of A-tier sites?
For #1 to benefit Mozilla, we need large video sites that are already
gathering this information and willing to share it with us. YouTube is.
I don't know about other sites. To reduce the threat of #3, we could
restrict the whitelist to https://youtube.com, excluding HTTP and
"youtube-nocookie.com".
On 6/16/15 3:51 PM, Jeff Gilbert wrote:
Yes, perpetual workarounds are an issue, but we can't handle this sort of
debugging at scale. Further, this would have been even faster (particularly
for less-common hardware) if the reporter could tell us exactly which
hardware an issue is present on. Historically, it has been difficult to
reproduce many reported bugs, and playing telephone between
gecko-dev/website-dev/user-with-issue is excruciating, and means that some
bugs will literally go unfixed anyway.
We also *cannot* ship most workarounds with our driver blacklist info,
since they usually require new code. Site-local workarounds are a strong
desire for A-tier sites because we simply *cannot* respond fast enough,
particularly on the Release branch. (or even late Beta)
Ideally, we'll eventually have enough of a handle on the long tail of
driver bugs that we can look at sunsetting this. We could include an entry
in the blacklist download to force problematic hardware to expose this info
(once we identify them as such!), while leaving believed-good hardware
masked off. We could start putting this together already, though I don't
know if we're confident enough in having any driver on the whitelist yet.
On Tue, Jun 16, 2015 at 7:25 AM, Jeff Muizelaar <jmuizel...@mozilla.com>
wrote:
A concrete example of this kind of thing occurred a little while ago
with Google Maps. They reported that users on G41 class hardware were
getting distortion when zoomed out in earth mode. This was because of
our switch to D3D11 ANGLE. When we got this report we were able to
reproduce the problem and block D3D11 ANGLE on that hardware. Google
Maps blacklists this hardware when it can detect it using
WEBGL_debug_renderer_info and if we had been exposing
WEBGL_debug_renderer_info we would not have found this problem as
quickly as we did.
We would've been able to find this problem even faster if we had a
better way for users to get this information to websites. The current
process with Google Maps seems to require users to complain on their
forum, for Google to ask them for the output of dxdiag and for them to
manually see a pattern in the output. This is obviously a process with
very low success and it seems like we could do something to make it
better.
-Jeff
On Mon, Jun 15, 2015 at 9:18 PM, Jeff Muizelaar <jmuizel...@mozilla.com>
wrote:
I'm concerned this will discourage websites from reporting WebGL
issues because it will be easier just to block whatever device has the
problem they're running in to. This creates an additional burden on
the web developer and essentially creates the user agent problem all
over again, but at much worse scale because of the wide range of
possible devices. This may be manageable for very large developers
like Google but I don't think it scales across web developers. We are
typically in a better position to control and update any WebGL
blacklist.
I've suggested that creating an easy way to rely diagnostic
information to a website in the event of a problem is a better
solution for improving the overall quality of our WebGL implementation
and sharing that benefit with all websites instead of just benefiting
large properties like Google's.
-Jeff
On Mon, Jun 15, 2015 at 7:16 PM, Jeff Gilbert <jgilb...@mozilla.com>
wrote:
Summary:
The WEBGL_debug_renderer_info extension allows for querying which driver
(and commonly GPU) a WebGL context is running on. Specifically, it
allows
querying the RENDERER and VENDOR strings of the underlying OpenGL
driver.
By default, RENDERER and VENDOR queries in WebGL yield safe but useless
values. (For example, Gecko returns "Mozilla"/"Mozilla" for
RENDERER/VENDOR) Queries to UNMASKED_RENDERER_WEBGL and
UNMASKED_VENDOR_WEBGL yield the RENDERER and VENDOR string of the
underlying graphics driver. These values are combined to form the "WebGL
Renderer" field in about:support. On my system, these are:
* UNMASKED_RENDERER_WEBGL: "ANGLE (NVIDIA GeForce GT 750M Direct3D11
vs_5_0
ps_5_0)"
* UNMASKED_VENDOR_WEBGL: "Google Inc." [1]
Bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1171228
Link To Standard:
https://www.khronos.org/registry/webgl/extensions/WEBGL_debug_renderer_info/
Do other browser engines implement this:
Chrome and IE implement this; Safari does not.
Platform Coverage: All platforms.
Current Target Release: Firefox 41
Related Preferences:
* "webgl.disable-debug-renderer-info" (default: false): Disable this
extension for unprivileged content.
* "webgl.renderer-string-override" (default: ""): Overrides
UNMASKED_RENDERER_WEBGL query result when non-empty.
* "webgl.vendor-string-override" (default: ""): Overrides
UNMASKED_VENDOR_WEBGL query result when non-empty.
Security and Privacy Concerns:
* Traditional user-agent sniffing concerns. (Known antipattern)
* This info includes what GPU is being used, which may contribute to
marketing profiles.
* This info adds easily-accessible bits of entropy that improve
fingerprinting, reducing privacy. (Panopticlick and others have
demonstrated that this is already very effective)
Web Developer Use-Cases:
* Sites can more easily and immediately identify and address concerns
caused by specific hardware or drivers. Currently, apps must
unconditionally workaround an issue until we can ship a fix via browser
updates.This can mean performance degradation for unaffected machines
for,
sometimes for weeks.
* Sites can collate and cross-reference drivers and hardware when
tracking
issues both user-reported and auto-detected, which both helps sites
identify problematic hardware, and helps browsers fix these issues in
turn.
* This allows sites to offer better estimates of performance, and offer
reasonable defaults for quality settings.
[1] On Windows, we use ANGLE as an intermediary driver on top of D3D,
hence
the VENDOR string being "Google, Inc." and not "NVIDIA" here.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
