Opened 4 months ago

Closed 3 months ago

#26670 closed defect (fixed)

Cannot allow Canvas Image Extract in tbb 8.0a9

Reported by: Ephraim Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: ff60-esr, TorBrowserTeam201808R
Cc: arthuredelstein, mcs, brade Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

torbrowser 8.0a9 under linux doesn't prompt on canvas image extract, instead it _always_ blocks canvas extract (even though default is prompt)
And even if manually set to "Allow" via site permissions it still blocks it.

Child Tickets

Change History (16)

comment:1 Changed 4 months ago by cypherpunks

I noticed that too in #26590#comment:3

I remember that with the ff52-esr switch the canvas popup didn't show up as well until it was fixed.

comment:2 Changed 4 months ago by tom

The behavior was changed in 60 to automatically block canvas extraction (without prompting) if it's triggered without user input. This new behavior is governed by the pref privacy.resistFingerprinting.autoDeclineNoUserInputCanvasPrompts

If you flip that to 'false' does it behave the way you expected it to?

comment:3 Changed 4 months ago by mcs

Status: newneeds_information

comment:4 Changed 4 months ago by Ephraim

Unfortunately not. privacy.resistFingerprinting.autoDeclineNoUserInputCanvasPrompts=false enables the prompt, but even if I decide to allow it asks again and again in an endless loop

comment:5 in reply to:  4 Changed 4 months ago by tom

Replying to Ephraim:

Unfortunately not. privacy.resistFingerprinting.autoDeclineNoUserInputCanvasPrompts=false enables the prompt, but even if I decide to allow it asks again and again in an endless loop

Sorry for the slow reply.

Hm. Is this a public website we could try out also?

And just to confirm, a TBB 7.5 browser (one based on ESR52), doesn't do the same thing?

comment:6 Changed 4 months ago by Ephraim

Unfortunately not a public site, but any site using canvas extract should do it.
for example this:

https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_canvas_getimagedata

the endless loop is just caused by the site I'm using is frequently using getImageData
to scroll a graph, but as you can see on the w3schools page, the Allow option doesn't
work, and the prompt appears again when you click the copy button again.

So it's sufficient for testing

And yes, in TBB 7.5 it just works fine. TBB 7.5 prompts, I select "Allow in the future" and it works and doesn't ask again for the current session (even though the very first getImageData was blocked anyway)

comment:7 Changed 4 months ago by tom

This is valid.

I was confused by this because I thought I had pretty thoroughly tested canvas extraction in FF. I had. FF with RFP does not exhibit this behavior. Tor Browser 8.0a9 does. I don't know why though.

comment:8 Changed 4 months ago by arthuredelstein

Cc: arthuredelstein added

comment:9 Changed 3 months ago by gk

FWIW: https://people.torproject.org/~brade/tests/canvasTest.html has some tests. We might want to look at the pointInStroke() one figuring out why it is failing both in the data access allowed case and in the case where access is prohibited.

comment:10 Changed 3 months ago by arthuredelstein

Keywords: TorBrowserTeam201808R added
Status: needs_informationneeds_review

comment:11 Changed 3 months ago by gk

Cc: mcs brade added

Looks good to me. mcs/brade can you have a second look and do a bit of testing? For instance, I am wondering whether it fixes the issue in comment:9. If not, then we probably should investigate that.

comment:12 Changed 3 months ago by mcs

Keywords: TorBrowserTeam201808 added; TorBrowserTeam201808R removed
Status: needs_reviewneeds_revision

Kathy and I reviewed the patch and did some testing. The only problem we see is that by changing the "Must belong to some other window" check in browser.js to be based on host, canvas prompts are opened in tabs that happen to match the host even if no canvas activity takes place there. We tested this by opening these pages in two browser windows:

https://people.torproject.org/~brade/tests/canvasTest.html
https://people.torproject.org/~brade/tests/

It would be good to fix this.

We also noticed that in Tor Browser the canvas permission status is not displayed within the control center (page identity popup) like it is in Firefox ESR60. That may be a separate issue though.

comment:13 in reply to:  12 ; Changed 3 months ago by arthuredelstein

Keywords: TorBrowserTeam201808R added; TorBrowserTeam201808 removed
Status: needs_revisionneeds_review

Replying to mcs:

Kathy and I reviewed the patch and did some testing. The only problem we see is that by changing the "Must belong to some other window" check in browser.js to be based on host, canvas prompts are opened in tabs that happen to match the host even if no canvas activity takes place there. We tested this by opening these pages in two browser windows:

https://people.torproject.org/~brade/tests/canvasTest.html
https://people.torproject.org/~brade/tests/

It would be good to fix this.

Good point -- you're right. Here's a new patch that doesn't touch the "correct browser" check in browser.js. So I believe this version fixes the problem.

https://github.com/arthuredelstein/tor-browser/commit/26670+1

We also noticed that in Tor Browser the canvas permission status is not displayed within the control center (page identity popup) like it is in Firefox ESR60. That may be a separate issue though.

Yes, this is a bigger issue for FPI of permissions that we didn't address in our Tor Browser patch. I think we should keep the issue separate, because it's going to be substantial work. I hope to address it in https://bugzilla.mozilla.org/show_bug.cgi?id=1330467.

comment:14 in reply to:  13 Changed 3 months ago by mcs

Replying to arthuredelstein:

Good point -- you're right. Here's a new patch that doesn't touch the "correct browser" check in browser.js. So I believe this version fixes the problem.

r=brade, r=mcs
This looks good to us, and it seems to work.

comment:16 Changed 3 months ago by gk

Resolution: fixed
Status: needs_reviewclosed

Looks good. Cherry-picked to tor-browser-60.1.0esr-8.0-1 (commit 79db24856a23ec7ae1f6d8cf46919a499ae5bb9f).

Note: See TracTickets for help on using tickets.