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

Q: Canvas fingerprint when using RFP + CanvasBlocker #767

Closed
quantizzed opened this issue Jul 28, 2019 · 7 comments
Closed

Q: Canvas fingerprint when using RFP + CanvasBlocker #767

quantizzed opened this issue Jul 28, 2019 · 7 comments

Comments

@quantizzed
Copy link

@quantizzed quantizzed commented Jul 28, 2019

Hi!

I'm a bit confused with the way canvas fingerprint is handled when using RFP.

IIRC, when RFP is enabled, Firefox is supposed to:

  • request the user's permission whenever a website tries to extract the canvas fingerprint;
  • spoof the real fingerprint with a constant value.

However, I have an impression that at least some websites (e.g. Panopticlick and Browserleaks) are able to read the canvas fingerprint without directly asking for permission or even when I have explicitly blocked its extraction.

Now, I also have the CanvasBlocker addon set up to fake API readouts, and it seems that it's only able to do its job when I explicitly allow a website to extract the canvas fingerprint. But whenever a site is able to bypass my permission, it just gets that constant value supplied by RFP.

Where am I being wrong, and is it possible to make Firefox always let CanvasBlocker handle the faking (and keep RFP enabled at the same time)?

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member

@Thorin-Oakenpants Thorin-Oakenpants commented Jul 28, 2019

🔻 FF58

  • 967895 prompt (site permission) before allowing canvas data extraction
    • FF59: 1413780 when RFP=true include canvas in site permissions panel
    • FF59: 1376865 reduce canvas prompt fatigue by only prompting when user initiated (controlled by a temp pref privacy.resistFingerprinting.autoDeclineNoUserInputCanvasPrompts )

request the user's permission whenever a website tries to extract the canvas fingerprint

Only when user initiated

is it possible to make Firefox always let CanvasBlocker handle the faking (and keep RFP enabled at the same time)

No. See #350 > Canvas.

If you're using RFP, then you need to look the same as other RFP users. As soon as you change something, then you stand out. It's an all-in buy-in or nothing.

@kkapsner can offer more insight: CB does not alter the RFP canvas, which as you correctly said, is static (it's a white canvas) - but I'm pretty sure that's by design: I'm not an extension developer, but I think an extension could override it. Example: extensions overriding RFP when it comes user agent/navigator properties: because the extension is the last one to modify it. A am not suggesting at all that this (RFP canvas override) be implemented as an option, just checking in with kkapsner for clarification

@kkapsner

This comment has been minimized.

Copy link

@kkapsner kkapsner commented Jul 28, 2019

CanvasBlocker sees the actual content of the canvas and it then fakes the output. BUT RFP kicks in afterwards (I do not investigate the exact details as it's the way I would like it to be - I do not even know if it's possible to have it in another way and if so I will not implement it in CB). So the page only sees the canvas content if RPF is disabled or the site is allowed to use canvas.

You can have a little peak behind the curtain by enabling RFP, storing the notification data and the image data for the notification in canvasblocker (two settings of CB) and go to https://canvasblocker.kkapsner.de/test/test.html
On the page you will see the white output the page sees and in the notification you see that CB got the real canvas content.

@quantizzed

This comment has been minimized.

Copy link
Author

@quantizzed quantizzed commented Jul 28, 2019

If you're using RFP, then you need to look the same as other RFP users.

Well, there are probably very few RFP users overall, and, therefore, a good chance to be the only one on a randomly picked site, so I thought being always unique with a new canvas fingerprint would be a better strategy, than being persistently unique.

See #350 > Canvas.

Thanks, this seems to answer all my questions. So, IIUC,

  • CB is currently pretty much useless, since having RFP enabled results in giving off the static fingerprint value anyway;
  • CB comes into play only when I explicitly allow access to my real canvas, and serves a fake value instead;
  • always faking by default is not yet possible, until Firefox introduces a pref for a default permission.
@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member

@Thorin-Oakenpants Thorin-Oakenpants commented Jul 28, 2019

Well, there are probably very few RFP users overall, and, therefore...

Your only hope is that the set of users you are in, conform to a standard. Uptake is important (obviously: that's what entropy is all about), but not as important as not breaking the rules and diverging. As soon as you diverge: you splinter from the main pack: and stand out.

Assuming (thanks @kkapsner for explaining that it's not ) you can alter RFP's canvas (aside from allowing site exceptions)... lets take the case of RFP vs RFP with canvas always randomized: even per domain and even per tab/session, so it's consistent within that domain). It is trivial to detect that you are a RFP user: now your canvas will not be the default white canvas spoof: therefore you are now (ultra super highly likely) in a much smaller set than if you had just left RFP alone. I say highly likely, because it is not impossible that 50% or more of RFP users would do this. But it's not going to happen.

This is why RFP needs to lock down people fiddling with it and thinking they know better. This is why Tor Browser tell people not to fiddle with settings, and not to install extensions.

PS: This is not about the effectiveness of raising entropy vs lowering it. There are pros and cons to both. RFP chose to lower canvas entropy.

@Thorin-Oakenpants

This comment has been minimized.

Copy link
Member

@Thorin-Oakenpants Thorin-Oakenpants commented Jul 28, 2019

always faking by default is not yet possible

Yes it is. RFP fakes by default: as a white canvas. I think you meant randomize.

@crssi

This comment has been minimized.

Copy link
Collaborator

@crssi crssi commented Jul 28, 2019

CB is currently pretty much useless

Not true.

  1. If you decide to allow access to canvas (due to breakage otherwise), then CB kicks in.
  2. CB is much much more than only canvas blocker. It covers also other vectors.
@quantizzed

This comment has been minimized.

Copy link
Author

@quantizzed quantizzed commented Jul 28, 2019

  1. If you decide to allow access to canvas (due to breakage otherwise), then CB kicks in.

But before I allow access to canvas, I've already given off RFP's static fingerprint.

  1. CB is much much more than only canvas blocker. It covers also other vectors.

You're right, of course, my bad, I've missed this important point.

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
4 participants
You can’t perform that action at this time.