webgl is not blocked with a click-to-play button

NoScript is doing this. I don't think we want this since we are already applying a Firefox patch to homogenize webgl fingerprints.

added TorBrowserTeam201901 component::applications/tor browser owner::tbb-team priority::medium resolution::fixed severity::normal status::closed tbb-usability type::defect labels

Trac:
Keywords: N/A deleted, tbb-usability, tbb-security-slider added

Yes, that's because WebGL is a privacy problem and, looking at the data from past sec-high and sec-crit bugs, not a security problem. Which is why it is not governed by the security slider and I think that's okay.

Here is what we are doing right now according to the design spec:

First, WebGL Canvases have click-to-play placeholders (provided by NoScript), and do not run until authorized by the user. Second, we obfuscate driver information by setting the Firefox preferences webgl.disable-extensions, webgl.min_capability_mode, and webgl.disable-fail-if-major-performance-caveat which reduce the information provided by the following WebGL API calls: getParameter(), getSupportedExtensions(), and getExtension(). To make the minimal WebGL mode usable we additionally normalize its properties with a Firefox patch. 

It seems your report is not a bug then. Maybe you wanted to argue we should not do the click-to-play thing at all anymore?

Trac:
Status: new to needs_information
Keywords: tbb-security-slider deleted, N/A added

Replying to gk:

Yes, that's because WebGL is a privacy problem and, looking at the data from past sec-high and sec-crit bugs, not a security problem.

Since we last looked at this, there have been some sec-high and sec-crit bugs related to WebGL: https://www.mozilla.org/en-US/security/advisories/mfsa2017-29/#CVE-2017-7845 https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7824 https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7754 https://www.mozilla.org/en-US/security/advisories/mfsa2017-14/#CVE-2017-5031 https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5459 https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5411

Which is why it is not governed by the security slider and I think that's okay.

You're right -- if it's privacy problem then we may want to block it at Low Security regardless of whether it's a security problem.

First, WebGL Canvases have click-to-play placeholders (provided by NoScript),

I have tried a number of webgl demos at https://experiments.withgoogle.com/chrome and I haven't found any sites where a click-to-play icon appears. The only way to enable WebGL appears to be to click on the NoScript button and then select one of the menu options to temporarily unblock webgl for that site.

So it would be nice to have a click-to-play button in the middle of a canvas, similar to how a click-to-play button is shown in YouTube. Or perhaps an easier alternative would be some sort of door hanger that says something like "To protect your privacy, Tor Browser has blocked advanced graphics on this site. Would you like to temporarily allow them anyway? (Yes/No)"

Trac:
Summary: webgl is getting blocked in low security to webgl is blocked without a click-to-play button

Trac:
Cc: N/A to dmr

Replying to arthuredelstein:

Replying to gk:

First, WebGL Canvases have click-to-play placeholders (provided by NoScript),

I have tried a number of webgl demos at https://experiments.withgoogle.com/chrome and I haven't found any sites where a click-to-play icon appears.

Talking about NoScript Quantum here, so it might be off-topic regarding the original discussion, but I'm told Tor Browser "Quantum" is finally on its way too, so...

I've tried the first WebGL demo linked from there, https://demo.marpi.pl/biomes/ , and if I assign marpi.pl a CUSTOM preset with all capabilities enabled except "webgl", I can see two placeholders (one for each canvas), allowing me to click-to-play webgl on that demo.

NoScript 10.1.8.2. Hope it helps.

Trac:
Status: needs_information to new
Keywords: N/A deleted, TorBrowserTeam201812 added

So, if you untick webgl as you do for media, then you can see click-to-play placeholder in http://webglsamples.org/aquarium/aquarium.html

Trac:
Username: spanish
Summary: webgl is blocked without a click-to-play button to webgl is not blocked with a click-to-play button

bug_21805 (https://gitweb.torproject.org/user/gk/torbutton.git/commit/?h=bug_21805&id=e2051e588405377f68c7899a8a8402faf82aab9c) has a patch for review. We might think harder, though whether we want to treat WebGL specially compared to other active content in that we make it click-to-play on any security level AND have fingerprinting defenses in place. One alternative to the current model would be to put WebGL on the security slider like we do with other features, like media. Especially as I agree with Arthur that there are more and more issues security-wise.

https://www.mozilla.org/en-US/security/advisories/mfsa2018-29/#CVE-2018-12407 https://www.mozilla.org/en-US/security/advisories/mfsa2018-29/#CVE-2018-17466

just popped up this week.

(Note though, treating WebGL content like we do treat media content would make it less security compared to the status after fixing this bug as there would be no click-to-play placeholder anymore on the default level.)

Trac:
Keywords: TorBrowserTeam201812 deleted, TorBrowserTeam201812R added
Status: new to needs_review

Moving review tickets to 2019.

Trac:
Keywords: TorBrowserTeam201812R deleted, TorBrowserTeam201901R added

This patch looks reasonable to me.

Trac:
Keywords: TorBrowserTeam201901R deleted, TorBrowserTeam201901 added
Status: needs_review to merge_ready

Thanks. This is now on master (commit 4306713f498584d85e9e7a3e2468d59126f9d3e0).

Trac:
Resolution: N/A to fixed
Status: merge_ready to closed

closed

mentioned in issue #27290 (moved)

mentioned in issue #29246 (moved)

moved to tpo/applications/tor-browser#21805 (closed)

mentioned in issue tpo/applications/tor-browser#29246 (closed)