can anyone else reproduce on nightly?

Has privacy.resistFingerprinting.pbmode:true ever worked? Once I switch it off I am immediately getting cached values in 119.0a1 again (it's even more broken in older nightlies).

Regression range (maybe, because I haven't tested the RFPLite prefs):

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=c6453931ce30e85a09f5568bd5fa0c93944906ea&tochange=ed3de2af4538a15a1f4e791e5eaf4eab9658f813

Has privacy.resistFingerprinting.pbmode:true ever worked?

yes #1716 (comment)

- RFP false, false | FPP false, false | both nothing
- RFP false, false | FPP false,  true | normal = nothing, pbmode = fpp
- RFP false, false | FPP true,  false | both fpp
- RFP false, false | FPP true,   true | both fpp

^ when rfp is off, fpp works as advertised

Once I switch it off I am immediately getting

per-execution and cached only show if the canvas is being spoofed. I would need to know the other three pref values. This is getting a bit noisy.

Can no-one else reproduce my bug with the exact same steps? I'm not making this up, look at the pic. I feel like I'm going mad

I'm make sure to always close all instances of my TZP test and to then retest in a new tab. The pic shows two open at the same time, but they are different window modes, and I get the same result if I did close them - this was just done for the pic

why: because some things are tied to the "cookie store" (not an actual cookie) and do affect some RFP results (such as css) - and workers can be long lived. IDK if that makes a difference exactly here, since we're only testing a binary RFP vs FPP. IMO these aren't really meant to be toggled mid session, and pages need reloading to take effect, and there may be some quirks.

Of course just testing canvas may work on it's own: edit, nope, it fails (you do need to do a F5/reload or whatever)

super simplified STR (ignore private windows)

• open a new profile, don't use beta or earlier
• this is all in normal windows, do not use a pb window
• open tab about:config, type resist (both should be false)
• open tab about:config, type printingpro (only pbmode should be true)
• open the test: https://arkenfox.github.io/TZP/tests/canvasnoise.html
  • control: EXPECTED: green matches (no one is spoofing any canvas)
• toggle privacy.fingerprintingProtection = true
  • reload the test, F5
  • control: EXPECTED: red and cached (means spoofing is persistent = FPP)
  • means: FPP is working
• toggle privacy.resistFingerprinting.pbmode = true (i.e only change pb mode)
  • reload the test, F5
  • control: EXPECTED: red and cached (means spoofing is persistent = FPP)
  • what we got: red and per-execution (= RFP, also the canvas pattern gives it away)

for the love of pizza, can someone else reproduce?

Windows 10 22H2, completely new profile

• open tab about:config, type resist (both should be false) -- confirmed
• open tab about:config, type printingpro (only pbmode should be true) -- confirmed
  
• toggle privacy.fingerprintingProtection = true
  
• toggle privacy.fingerprinting.pbmode = true (i.e only change pb mode) -- I assume you meant privacy.resistFingerprinting.pbmode?
  
  also yes, RFP pattern in the second canvas
  may I ask what STR here means?

STR = steps to reproduce

I assume you meant privacy.resistFingerprinting.pbmode

yup, have edited my simple STR

sorry for the thumbs up and tadas - I'm just elated someone else can replicate (otherwise I am going mad and was going to retire from the internet and give up), not elated that there is a bug

reproduced in MX linux so yeah seems to be a FF bug
also the cells changed count with FPP enabled shot up to 142 for me once...

also the cells changed count with FPP

Each time you run, the control test is random - i.e r, g and b values are anything from 0 to 155 255. Because I know the values of every single pixel (400 of them, 20 x 20), I can detect which ones change and which values

So even a cached spoofing will change every test, because the control is random

The figures are just some old code I used to fingerprint the spoof. e.g. RFP just totally randomizes in a pattern. So the chances that all 400 pixels or cells change is very high, i.e to get a collision would require all four randomized r, g, b, a values in that cell to match my control ones, which is not mathematically impossible, but super unlikely. But as you can see, not every spoofed value is always different - 400 pixels x 4 values = 1600 data points

so here, below, is RFP and it shows all 400 pixels were altered in some way, but not all of them for all 4 channels - e.g. r is 398, so the randomized r value on two pixels were the same, etc .. which is about right - 1 collision in 256

cells changed: 400
channels changed: 4 [rgba]
channel counts: r: 398, g: 399, b: 397, a: 400
combos altered: 4 [gba, rba, rga, rgba]
combo counts: {"rgba":394,"rba":1,"gba":2,"rga":3}

the other bit is by how much it changes the r, g, b , a value.

a lot of extensions, and even built protections like RFP or brave's farbling, are pretty stable in these values: what channels are changed, % of pixels affected, % range of altering the value

FPP seems to be always alter the value ± 1 (range 2), and always alters r,g,b and never a, but the percentage seems to vary wildly - I said in the other post I ranged in a few tests from 10 to 100 (it's wider than that, I saw a 6/400 and you just got a 126 142/400)

cells changed: 94
channels changed: 3 [rgb]
channel counts: r: 37, g: 28, b: 39, a: 0
combos altered: 7 [b, g, gb, r, rb, rg, rgb]
combo counts: {"b":32,"g":22,"rb":3,"r":31,"rg":2,"gb":3,"rgb":1}

r: 2 [-1 to 1, 2] 22/15 ... 1 [1 to 1, 0]
g: 2 [-1 to 1, 2] 11/17 ... 1 [1 to 1, 0]
b: 2 [-1 to 1, 2] 13/26 ... 1 [1 to 1, 0]
a: n/a

anyway, the point of these was so I can fingerprint the anti-fingerprinting

reproduced on my end as well (macOS)

well, it could be that I have no idea what I'm doing and am completely wrong (wouldn't be the first time)

per-execution and cached only show if the canvas is being spoofed. I would need to know the other three pref values. This is getting a bit noisy.

Sorry. I should have mentioned that I did ran mozregression with the following prefs set

{
	"privacy.resistFingerprinting": false,
	"privacy.resistFingerprinting.pbmode": true,
	"privacy.fingerprintingProtection": true,
	"privacy.fingerprintingProtection.pbmode": false
}

well, it could be that I have no idea what I'm doing and am completely wrong (wouldn't be the first time)

But if I ran https://ritter.vg/misc/ff/canvas.html with the same prefs I keep getting randomized canvas in a normal window, and canvas permission prompt every time I click on "Extract". How is that even possible?

Nightly, Windows

Fresh Profile:

control | 944de62d \| 1fd70937
-- | --
1st read | 944de62d \| 1fd70937 [matches]
2nd read | 944de62d \| 1fd70937 [matches]
stats |  
diffs |  

FPP.pbmode On:

control | 362f0ad1 \| de7ccb93
-- | --
1st read | e49c4446 \| 3ed22174
2nd read | e49c4446 \| 3ed22174 [cached]
stats | cells changed: 106 channels changed: 3 [rgb]   channel counts: r: 38, g: 40, b: 35, a: 0   combos altered: 6 [b, g, gb, r, rb, rg]     combo counts: {"g":34,"rb":1,"b":32,"r":33,"gb":2,"rg":4}
diffs | r: 2 [-1 to 1, 2] 11/27 ... 1 [1 to 1, 0]  g: 2 [-1 to 1, 2] 21/19 ... 1 [1 to 1, 0]  b: 2 [-1 to 1, 2] 19/16 ... 1 [1 to 1, 0]  a: n/a

RFP.pbmode On:

control | 9fa1d811 \| 47049ec9
-- | --
1st read | 69d88de1 \| 9e946e0d
2nd read | 3e499cd7 \| 25060c33 [per-execution]
stats | cells changed: 400 channels changed: 4 [rgba]   channel counts: r: 400, g: 397, b: 398, a: 400   combos altered: 3 [rba, rga, rgba]     combo counts: {"rgba":395,"rga":2,"rba":3}
diffs | r: 247 [-237 to 233, 470] 205/195 ... 180 [1 to 237, 236]  g: 236 [-221 to 205, 426] 245/152 ... 167 [1 to 221, 220]  b: 239 [-227 to 219, 446] 217/181 ... 161 [1 to 227, 226]  a: 8 [-252 to -18, 234]

So yes, I can reproduce this with canvas.

I also tested with performance.now from https://arkenfox.github.io/TZP/tests/timing.html but I don't think this test is that helpful, I would expect it to just call perf.now() as quickly as it could, and with RFP we should see coarse delineated steps, and without RFP it would have much finer steps. As it is, it seems to be trying to give you 24 ms increments, which is hard to do the math on what you expect to see.

I tried finding a page on TZP that just showed my timezone, but couldn't :-p I used https://everytimezone.com/

Nothing: expected value (local time)
RFP globally: expected value (UTC)
RFP.pbmode: expected value (local time)
RFP.pbmode in PBM: expected value (UTC)
FPP: expected value (local time)
FPP + RFP.pbmode in Normal mode: UNEXPECTED VALUE (UTC)

So it turns out that enabling RFP.pbmode, and FPP in regular mode causes the bug. You need both of those, individually they work as expected. Knowing this I went back and tested canvas, and got the same behavior.

I'll look at this next week, I'll file a bug on Tuesday if you don't get to it first :)

I tried finding a page on TZP that just showed my timezone

well it's right there ... https://arkenfox.github.io/TZP/tests/timezones.html - edit: you need to click [combine years]

timing

that's an old shitty test page, I plan (on my massive ToDo list) to make a much larger one that just iterates 50 different tests of whatever, so you just click run, and go make a cup of tea

fwiw, just using the main TZP test as per both OP here and in the other issue, shows all the green RFP health checks, so it;s not like you need to check timezone separately

I also tested with performance.now from https://arkenfox.github.io/TZP/tests/timing.html but I don't think this test is that helpful, I would expect it to just call perf.now() as quickly as it could, and with RFP we should see coarse delineated steps, and without RFP it would have much finer steps. As it is, it seems to be trying to give you 24 ms increments, which is hard to do the math on what you expect to see.

so back then we had 100ms clamping. But even today, clicking it I can easily see if RFP is working

• 1. the timings have decimal precision (dead giveaway)
• 2. the values are increments of 60FPS .. e.g. 16-or-17/32-or33/50/66-or-67/83/00 etc

50.001000000000204
83.33499999999913
100.00200000000041
133.33599999999933
166.66999999999825
200.00400000000081
233.33799999999974
266.67199999999866
283.33899999999994
316.67299999999886
350.0070000000014
383.34100000000035
416.6749999999993
450.0089999999982
483.34300000000076
516.6769999999997
550.0109999999986
583.3450000000012
616.6790000000001
650.012999999999
683.3470000000016
700.0139999999992
733.3479999999981
766.6820000000007
800.0159999999996

anyway, here's what TZP's main test does: examples

• 16.7, 16.6, 16.7, 16.7, 0, 16.6, 16.7, 16.7, 16.6 [✓ RFP]
• 16.7, 16.6, 33.4, 16.6, 16.7, 0, 16.7, 16.6, 16.7 [✓ RFP]
• ^ I'm recording the timings between reported values, allowing for some yank etc, which is what I think you just hinted at - beat you too it :)

But if I ran https://ritter.vg/misc/ff/canvas.html with the same prefs I keep getting randomized canvas in a normal window, and canvas permission prompt every time I click on "Extract". How is that even possible?

IDK. It's hard to follow and it's not my test - there's no easy way to tell if it's FPP, but the RFP one is easy to spot. Always F5 after changing the prefs

patch landed in nightly (123) 3 hrs ago (sorry for the delay in letting you all know) .... just need to test it

tested and verified - nightly 123 nope

ok, I thought I had a false result, but now can't replicate - maybe the order of changes, or something tied to the "cookie store/jar" (like css) or whatever they call it, but I'm always careful to close all existing tabs and test in new ones

closing for now