Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CanvasBlocker doesn't work if privacy.resistFingerprinting = true #158

Closed
notDavid opened this issue Nov 22, 2017 · 13 comments
Closed

CanvasBlocker doesn't work if privacy.resistFingerprinting = true #158

notDavid opened this issue Nov 22, 2017 · 13 comments

Comments

@notDavid
Copy link

@notDavid notDavid commented Nov 22, 2017

Fyi, it seems that in Firefox 58.0b5 if i set "privacy.resistFingerprinting = true" in about:config the canvas value is nolonger random - so the CanvasBlocker extension doesn't seem to work anymore. Tested at https://panopticlick.eff.org/

If i set it back to the default value "privacy.resistFingerprinting = false" CanvasBlocker works again.

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/privacy/websites#Properties

@kkapsner

This comment has been minimized.

Copy link
Owner

@kkapsner kkapsner commented Nov 23, 2017

Did you allow the canvas readout when Firefox asked you? CB will only do something if you allow it. Otherwise a generic white will be used.

@Thorin-Oakenpants

This comment has been minimized.

Copy link

@Thorin-Oakenpants Thorin-Oakenpants commented Dec 4, 2017

FF58 will prompt to block canvas with privacy.resistFingerprinting=true 967895

  • I do not know what happens if you block (I assume CB is never used?)
  • I do not know what happens if you allow (I assume CB then takes over?)

When you allow a site to extract canvas, it is a permanent solution ATM (although you can remove the offending items from permissions.sqlite - see https://www.reddit.com/r/firefox/comments/7bmmhp/how_do_you_accesschange_permissions_to_canvas/dpjk5qk/ on how to do this)

1413780 aiming for FF58 aims to add Canvas to site permissions, so you can undo it when you allow a site to extract

@kkapsner

This comment has been minimized.

Copy link
Owner

@kkapsner kkapsner commented Dec 4, 2017

@Thorin-Oakenpants: you are right.
@notDavid: does it work if you allow the canvas?

@notDavid

This comment has been minimized.

Copy link
Author

@notDavid notDavid commented Dec 4, 2017

@kkapsner Hi sorry for the late reply - i just tested again and indeed it works when i allow the readout.

Thanks for taking the time to explain :)

@notDavid notDavid closed this Dec 4, 2017
@kkapsner

This comment has been minimized.

Copy link
Owner

@kkapsner kkapsner commented Dec 4, 2017

No problem - you're welcome. Thanks for rechecking.

@Thorin-Oakenpants

This comment has been minimized.

Copy link

@Thorin-Oakenpants Thorin-Oakenpants commented Dec 6, 2017

FYI: as a follow up on what I said 4 comments up ...

1422862 OffscreenCanvas doesn't respect Canvas Permission Prompt

also: for nerds: 1422890 some testing still to be done

  • canvas.toDataURL
  • canvas.toBlob
  • canvas.mozGetAsFile
  • canvas.isPointInPath

So until fully tested and verified, the FF58+ canvas prompt, and FF59(likely) canvas site permission is kinda hit and miss and CB is definitely a great fallback

Personally I block now, but once this becomes properly implemented, the best strategy IMO is to fake. That is block all with RFP (resist.Fingerprinting), but when you allow a site to extract canvas (in order for it to work), then fake it (so it still works) but use whitelisting (if unavoidable).

@kkapsner : does the nerd link above make sense to you (it's all over my head). Also, is offscreencanvas common?

@kkapsner

This comment has been minimized.

Copy link
Owner

@kkapsner kkapsner commented Dec 8, 2017

The link kind of makes sense - I just do not get why they prompt for isPointInPath but neither getImageData nor readPixels...

offscreen canvas should not be too common for usual applications. But for example the fingerprinting on https://www.browserleaks.com/canvas is offscreen.

PS: With the next version you will have even more options than a white listing. You can then specify the block mode specific for one site.

@tomrittervg

This comment has been minimized.

Copy link

@tomrittervg tomrittervg commented Dec 20, 2017

Hey all, I'm a Mozilla person working on this. Despite Bug 1422890, we believe all those APIs are correctly spoofed (they provide fake data) unless the permission is granted.

We do prompt for getImageData. I'm investigating readPixels - I think in Tor Browser WebGL is click to play and that's why it's not addressed in our solution so in FF this may be a problem...

OffscreenCanvas is not enabled in Firefox yet; if you turn it on by flipping a pref we do not apply fingerprinting resistance to it.

I appreciate the investigation, if you have any other comments/concerns about this type of stuff in Firefox, feel free to reach out to me! https://ritter.vg/contact.html

@Thorin-Oakenpants

This comment has been minimized.

Copy link

@Thorin-Oakenpants Thorin-Oakenpants commented Dec 20, 2017

FYI : for those playing along at home

/* 2028: disable offscreen canvas
 * [1] https://developer.mozilla.org/docs/Web/API/OffscreenCanvas ***/
user_pref("gfx.offscreencanvas.enabled", false);

Note: default is false (FF57)

@Thorin-Oakenpants

This comment has been minimized.

Copy link

@Thorin-Oakenpants Thorin-Oakenpants commented Dec 22, 2017

FYI: 1413780 has landed, so you should be able to use this in testing on Nightly. That's the ticket that now puts canvas blocking as an item in the site permissions panel (so you can undo any prompt you said to allow(+remember) etc)

@MarkFirewhal

This comment has been minimized.

Copy link

@MarkFirewhal MarkFirewhal commented Jun 24, 2019

I am here because I accidentally doubled up on canvas fingerprint detection... double negative it seems.
I added some changes to my prefs.js and it paralyzed this addon. Mozilla's resistFingerprinting does little to spoof anything, and is useless alongside this addon.
user_pref("privacy.resistFingerprinting", true);

So if anyone else is here because pyllyukko/user.js#468 crippled CanvasBlocker... here's your fix.
THANKS!

@kkapsner

This comment has been minimized.

Copy link
Owner

@kkapsner kkapsner commented Jun 24, 2019

I'm not sure what you mean by "paralyzed". If I enable RFP everything works as expected. Is there anything to fix?

@Thorin-Oakenpants

This comment has been minimized.

Copy link

@Thorin-Oakenpants Thorin-Oakenpants commented Jun 24, 2019

Edit: apologies to the OP of this issue, my comments below refer to @lockntross 's comment two comments up. End edit.

cross posted from pyllyukko/user.js#468

Mozilla's resistFingerprinting does little to spoof anything, and is useless alongside CanvasBlocker.

^^ I cannot say this enough. This is absolutely terrible advice and not even a solution. Especially given that we don't know exactly what OP did, or how he did it, or any other details such as OS, Firefox version, CB version, and most importantly, what does "paralyzed" mean. That's not meant as a criticism of OP, it just needs clarifying, and may in fact be a genuine or potential bug.

  • first of all, don't edit prefs.js (as a general rule: you can if you know what you're doing, but it is not recommended). You should be using about:config for real time changes (although some prefs require a restart), or for more permanent changes use a user.js
  • OP states he paralyzed CB because he made changes to preferences. By default CB is not "paralyzed" (not sure what that means, the problem needs steps to reproduce (STR) and better analysis). This is a problem caused by OP (but may be a valid bug)
  • Stating that the solution is to set *privacy.resistFingerprinting` to false is not a solution. The real solution is to find out exactly what OP did to cause CB for him/her to fail.
  • RFP does far more (well over a hundred anti-fingerprinting measures) than just canvas protection, including some protections that cannot be solved outside of those provided by the Tor Uplift/RFP (e.g css media spoofing).

tl;dr: OP brought this issue on himself as CB & RFP work together out of the box (but what he did may be a valid/potential bug), and while disabling RFP clearly stops the conflict, it also causes far more harm than any good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.