use more randomizing where it makes sense
lets utilize/hook-into FPPs random seed per eTLD+1 + scheme, per session, per window type
One thing I have been doing in TZP is detecting spoofs/lies. Many of these are mathematical: known pixel tests in canvas, domrect lies from a known sized element, textmetrics char widths must be 1/128ths (some exceptions), and you can measure two glyphs individually + combined to expose spoofing, etc.
But some things are just too hard [1] to determine if it is fake (obviously a persistent lie, not random per execution), and some of them don't seem to affect web content (or super rare). By this I don't necessarily mean by web extensions (which can leak prototype/proxy lies), but when it is implemented by the browser. See [1] below, we're not going to fool an advanced script, but naive ones abound. The more we randomize the better the odds we fool a script - this is especially helpful in MB. Also note that other ways to detect randomness is to use a 3rd party and compare to first party, but this increases the FP cost.
Examples I can think of that are super hard to detect
- hardwareConcurrency: we currently spoof at 2
- why not randomize between [2, 4, 6, 8, 12, etc] <- set of real world values
- screen/available screen (and @media/css)
- I have already suggested that we return a smaller set of sizes for these based on inner, but we could just always return a random size that is inner + a range, we could even split these two to create more noise
- storage estimate, see #41065
- we could jitter a heap of noise here based on a hardcoded value - priceless!
[1] Not to be confused with knowing you are TB and we know what you protect so we can know that the value is untrustworthy
cc: @tjr