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.
Trac: Username: Ephraim
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
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?
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
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?
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)
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.
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.
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.
Trac: Cc: arthuredelstein to arthuredelstein, mcs, brade
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.htmlhttps://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.
Trac: Keywords: TorBrowserTeam201808R deleted, TorBrowserTeam201808 added Status: needs_review to needs_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.htmlhttps://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.
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.
Trac: Status: needs_revision to needs_review Keywords: TorBrowserTeam201808 deleted, TorBrowserTeam201808R added
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.