Opened 3 years ago

Closed 11 months ago

#21805 closed defect (fixed)

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

Reported by: arthuredelstein Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-usability, TorBrowserTeam201901
Cc: dmr Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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

Child Tickets

Change History (11)

comment:1 Changed 3 years ago by gk

Keywords: tbb-security-slider tbb-usability added

comment:2 Changed 3 years ago by gk

Keywords: tbb-security-slider removed
Status: newneeds_information

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?

comment:3 in reply to:  2 ; Changed 2 years ago by arthuredelstein

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

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)"

comment:4 Changed 20 months ago by dmr

Cc: dmr added

comment:5 in reply to:  3 Changed 18 months ago by ma1

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.

comment:6 Changed 12 months ago by gk

Keywords: TorBrowserTeam201812 added
Status: needs_informationnew

comment:7 Changed 12 months ago by spanish

Summary: webgl is blocked without a click-to-play buttonwebgl is not blocked with a click-to-play button

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

comment:8 Changed 12 months ago by gk

Keywords: TorBrowserTeam201812R added; TorBrowserTeam201812 removed
Status: newneeds_review

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.)

comment:9 Changed 11 months ago by gk

Keywords: TorBrowserTeam201901R added; TorBrowserTeam201812R removed

Moving review tickets to 2019.

comment:10 Changed 11 months ago by pospeselr

Keywords: TorBrowserTeam201901 added; TorBrowserTeam201901R removed
Status: needs_reviewmerge_ready

This patch looks reasonable to me.

comment:11 Changed 11 months ago by gk

Resolution: fixed
Status: merge_readyclosed

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

Note: See TracTickets for help on using tickets.