RFP's canvas silently blocks extensions from altering the canvas, but offscreen canvas does not adhere to the same rule

STR

• control
  • test site: https://canvasblocker.kkapsner.de/test/test.html
  • RFP on, no extension
  • test shows all tests as randomized by RFP (vertical stripey pattern)
• test
  • close previous test tab
  • enable extension - CanvasBlocker
  • run the test
  • test shows all tests except offscreen as randomized by RFP (vertical stripey pattern)

That is interesting, I do not know why that happens. I'm not aware of us explicitly doing anything with regards to canvas and extensions, so I suspect this is a side effect of something, and it's just not behaving the same way for OffscreenCanvas. But we should figure out what it is and normalize things I suspect, if only to make the behavior consistent and better understand why this is happening.

I think RFP does not apply in extension code. It should not be special for offscreen canvas.
CanvasBlocker should not leverage this behaviour (https://github.com/kkapsner/CanvasBlocker/issues/644) and goes out it's way to avoid it.

Oh, so the canvas is being noticed and rendered by the extension, and then feeding it back into the page? Yes that would bypass the RFP restrictions.

Oh, so the canvas is being noticed and rendered by the extension

isn't that what I said: allows extension override ?

Is there anything for us to actually do here? The CanvasBlock extension seems to have overwritten the canvas methods of the page and was then returning results based on a canvas created in the context of the extension, which doesn't get scrambled.

which doesn't get scrambled

it is subtlely randomized

control: no RFP, no CB

• record your offscreen hash(es): this is your real value

test RFP only

• flip RFP on = CB disabled, refresh page repeatedly
• offscreen hashes are random per execution as per RFP (wavy pattern)

test CB only

• enable CB (current stable v1.8 from Feb 20th 2022)
• refresh page repeatedly
• offscreen hashes are random per execution as per CB (subtle: canvas still looks the same to the human eye)
  • side note: I thought CB was meant to be persistent, and it is but not in offscreen, hence why I recorded the real hash in the control

test both

• CB enabled, RFP enabled
• refresh page repeatedly
• ALL tests except offscreen Test use RFP. offscreen Test doesn't, it is using CB (you can tell because it is not the real hash from control, and it is random per execution)

This is the issue: with all canvas + RFP, all but offscreen Test prevent extension's using the API. RFP canvas can be detected by it's characteristics, so it would be nice if all canvas played by the same rules. As a quirk of the earlier RFP patches, this happened to lock extensions out (which I think is great), but now offscreen leaves a difference that can be fingerprinted against those using something like CB (it's default is to randomize all canvas)

One valid use case that is used and has been advocated for: is to use RFP but when you add a canvas site exception for usability, it then falls back to subtle randomizing - thus still protecting and giving compat

One valid use case

this may be a moot point with FPP developments. I don't know where we're going with FPP canvas (which is for PB mode) here vs RFP canvas vs Tor Browser vs compat

Ideally, I think RFP canvas could be subtle randomizing, but that carries risk so IDK if Tor Project would like that- but I do know that Mullvad Browser and Firefox users definitely would, as part of RFP, as canvas use becomes ubiquitous even for editing, such as google platforms. Another option is for RFP canvas exceptions to fallback to subtle (not just in PB mode), but that would take some engineering and add complexity. And technically, we should always allow extensions to have the last say.

I just think we need to be consistent. It's not a priority - TB discourages extensions not already bundled, and RFP is not front facing :)

@Tom Schuster: I don't think there is something to to in Firefox. CanvasBlocker will change it's behaviour (fixed in https://github.com/kkapsner/CanvasBlocker/commit/269574ae17df04138bf02d0e01164167535b66b7) - I think I will submit the next version soon (maybe even today...).

@Simone Mainey: CB can be persistent when you chose the "persistent" rng.

Thanks - I had it set to non-persistent, must have been from something I checked in the past - thanks. Test steps still work, just compare real has from control

The severity field is not set for this bug.
:lsalzman, could you have a look please?

For more information, please visit auto_nag documentation.

The behaviour is fixed in version 1.9 of CB.

Thanks kkapsner! I'm going to resolve this as Invalid, from the perspective of Firefox.