"Detection test" page for CanvasBlocker does not bear the expected results

ajay-gh commented 7 months ago

When running each test of the test page(s),

with FF 124.0, and
all other extensions disabled, and
the default settings of CanvasBlocker (reset + stealth preset),

the "DetectionTest"page does not show the expected results.

Description

The test produces consistently two red lines:

known pixel value test 10: API tampering detected
readout - in - out test: API tampering detected when running it in all 4 recommended configurations ( all addons enabled/disabled, CB enabled but ... and CBdisabled)

Expected Behaviour

All lines should say "no tampering"

Current Behaviour

see above

Possible Solution

This could be (could this be ?) related to the fact that my user.js file for FF has the following three lines in it : javascript.options.baselinejit false
javascript.options.ion false
javascript.options.native_regexp false I cannot see any other preferences in the user.js file which could impact the test results. Any advice welcome !!

Steps to Reproduce (for bugs)

should be clear from above

Context

the fact that the detection page shows tampering means that protected website, e.g. with cloudflare, can detect "tampering" in my FF instance, this again could explain that more and more websites cause problems (as cloudflare services are found on more and more websites). tried, a fresh profile w/o any other addons does not show any tampering, but this configuration is not acceptable for general browsing / use.

Your Environment

CanvasBlocker Version used: version 1.9
Firefox version : 64-bit, v 124.0
Operating System and version (desktop or mobile): Macbook Pro, Monterey, 12.7.4
Installed addons: all disabled for the tests (usually using NoScript, uBlock)

Your Settings

the default settings of CanvasBlocker (after reset, stealth preset).

kkapsner commented 7 months ago

I'm not able to reproduce your problem (even with the changed browser settings). This is the output I get with default settings + stealth preset (without stealth only the "known pixel value test 10" fails, which is expected):

Do you have RFP (privacy.resistFingerprinting) enabled? ... but then more tests would be marked as tampered...

Since the tampering is also detected when CB is disabled it has to be some browser setting. I'm not sure if I can help you...

kkapsner commented 7 months ago

After checking #676 I saw that with ETP strict these tamperings are triggered. So there is your setting that causes that behaviour.

ajay-gh commented 7 months ago

This is correct. I am not using strict settings, but usually custom settings. When I disable "suspected fingerprinters" the reported problem foes away. I mistake on my side, but reporting it may still help other users when they run into the same problem. Thanks for your response !!

kkapsner commented 7 months ago

The report was and will be definitely helpful.

I think there is some lesson to be learned in every created issue - as long as there is a conversation when not everything is clear. (I often have to close issues because I cannot reproduce/understand the problem and the author is not responding...)

Thorin-Oakenpants commented 7 months ago

stealth preset

oh noes ... bad news ... you can't hide that either - see https://arkenfox.github.io/TZP/tests/canvasnoise.html

this is not using anything other then writing and reading canvas

it's a little weird, because it says persistent (that's for the reads), I'm only writing once, but reading twice. In reality I would also write a second time and compare for persistence in input

ohnoes

kkapsner commented 7 months ago

Nice approach but I also get a different reads from the control when I disable CB (or whitelist the domain):

Thorin-Oakenpants commented 7 months ago

I tweaked it, twice since my pic - not sure exactly what CB does

Originally I covered the entire background with the block unicode symbol, and then added random colors in a checkerboard pattern. So half was random and half was text underneath.

Then I tweaked the random pattern to do more of the area, rather than half. It now does 351/400 pixels

x and y are the columns/rows

// xEven + yEven == 1 = checkerboard = 1/2
// xEven + yEven == 2 = another 1/4
// xEven + yEven == 0 = the remainder: of which we can further reduce e.g. multples of 3
let go = (xEven + yEven == 1 || xEven + yEven == 2) // 1/4th
if (!go) {
    if ((x * y) % 3 == 0 ) {go = true} // brings us down to 1/8th or 50 pixels
}
if (go) {
// use a random color for this pixel
} else {
// do nothing!!! let the underlying font/font-color show
}

Then I tweaked it to start the entire canvas with the font color first (in case the unicode block symbols missed some pixels).

Then I decided I didn't need to actually write anything in text since I already set the underlying color - it still worked for me when I added a blank space, for example - it was simply the act of fillText that does the trick. And I'm always iffy about using things out of my control, such as the font used, etc - but the block symbol \u2588 is from unicode v1.0 (top of my head).

But I always seem to get 49pixels (out of 400) as tampered with. In my original pic you can see the checkboard was exactly half - 200/400. This isn't that important, the fact is that there was change.

In your image you only have 2/400 pixels changed .. weird .. again, I'm not 100% entirely sure what CB does but I think I'll change the text back to actually write those unicode blocks and cover the entire area, as it seems as if you only alter the .fillText part (when inputting so to speak ... which makes sense now I've had a sleep)

Thorin-Oakenpants commented 7 months ago

ok, I tweaked it back a little, to make the font affected area covered the entire canvas (hopefully) ... because by only writing a default font + default font size a as a trigger, for example, I got 15/400 (maybe I forgot to use a new browser session in one of my earlier tests). I think I get it now as to what CB is doing here - ~~1 random channel, change the entire font color?~~

ok, so it's seems like a consistent r+g value and yup .. now I can check that the only pixels changed are the font ones. Already added to TZP main test

Thorin-Oakenpants commented 7 months ago

sorry for the noise :) not!! 🧀

https://github.com/arkenfox/TZP/blob/88b30adb0bd14cbf5ec48cf676b1959ab3960be6/tests/canvasnoise.html#L156-L196

so it's problematic to test for just strokeText, but kinda doable since a zero curves (bezier noise) and as straight as possible horizontal/vertical line (reduce/eliminate aliasing) actual removes false positives on my machine. But to be honest, it's not worth it - who would protect strokeText but not fillText?

Anyway, had lots of fun and found an old bug in my canvas code too, so thanks :) TZP's next lot is to add solid color tests (FPP ignores them, as does CB or it should do, but RFP currently doesn't). And then I need some help to add more methods .. lookin' at you @kkapsner 🍕 🍺 come join the party at TZP

kkapsner / CanvasBlocker