User.js: Q: Canvas fingerprint when using RFP + CanvasBlocker

[quantizzed]

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]

:small_red_triangle_down: 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 https://github.com/ghacksuserjs/ghacks-user.js/issues/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]

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]

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]

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]

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]

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]

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.