Closed Bug 1897251 Opened 4 months ago Closed 4 months ago

layout.frame_rate has no effect if `privacy.resistFingerprinting` is enabled

Categories

(Core :: Privacy: Anti-Tracking, defect)

Product:
Core
Component:
Privacy: Anti-Tracking
Type:
defect

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: dholbert, Unassigned)

References

Details

(This is similar to bug 1863853, but bug is specifically about private-browsing-vs-regular-browsing leakage. This one is more direct.)

STR:

  1. Start Firefox with a fresh profile.
  2. (optional) Visit some page with CSS animations (e.g. this MDN page) and confirm that the animation is smooth. (Here's another testcase using Flickity which animates on right/leftarrow: https://codepen.io/dholbert/pen/XWwbrRK )
  3. Visit about:config and set layout.frame_rate to 1.
  4. Visit the page from step 2 and confirm that the animation is not-smooth.
  5. Visit about:config and set privacy.resistFingerprinting to true
  6. Visit the page from step 2 again.

ACTUAL RESULTS:
Animation is smooth again.

EXPECTED RESULTS:
Animation should still be not-smooth; or, users should perhaps have a way to make it not-smooth (perhaps some additional preference to let the frame-rate be an allowable fingerprinting target).

NOTE:
As noted in bug 1863853 comment 7, resistFingerprinting isn't really a supported configuration and it's known to reduce usability (in the service of making every user look as similar as possible to websites that might try to measure differences-between-users, which is the point of the pref).

However, given that some users use layout.frame_rate for a11y purposes, maybe it's worth adding an additional about:config option to let that preference be honored even with resistFingerprinting enabled?

(Side note for testing this: if you happen to be using Linux with Wayland, you may run into bug 1771017 which makes layout.frame_rate have no effect at all. You can avoid that by running export MOZ_ENABLE_WAYLAND=0 before starting Firefox from your terminal, per bug 1863853 comment 0.)

Noting that I use layout.frame_rate for accessibility purposes.

I also note that this behavior is inconsistent across different animations. I have the following items set in my current browser instance:

privacy.fingerprintingProtection true (overridden)
privacy.fingerprintingProtection.pbmode true (default?)
layout.frame_rate 1 (overridden)

MDN page with animations:

I'm getting a different result from Daniel Holbert on this one. Clicking any of the sample CSS buttons causes the circle to jump to its final position without visible animation. I can confirm this by setting layout.frame to 3 or 5 and see at least one intermediate step. So my frame rate setting is not being interfered with here for me.

But if I go to [Daniel Holbert's codepen example of Flickity] (https://codepen.io/dholbert/pen/XWwbrRK), that does smooth animate, so here I am getting the same experience as Daniel.

So there must be some additional code or setting at work here to explain the difference between those two websites.

Please consider whether it might work to deliver the desired layout.frame_rate to the user but lie to the website about the frame rate.

*layout.frame_rate

privacy.resistFingerprinting.pbmode is set to false (default)

(In reply to Chas Belov from comment #1)

privacy.fingerprintingProtection true (overridden)

Per bug 1894842 comment 20, I think you mean resistFingerprinting (not fingerprintingProtection). At least: resistFingerprinting is the one that matters for this bug here, and it sounds like you have that one set to true as discussed in bug 1894842.

I'm getting a different result from Daniel Holbert on this one.

(Hmm -- if you're really seeing differences between MDN animations page vs. Flickety, that's interesting. I can't reproduce that, but it's conceivable; the MDN page is using CSS animations, whereas Flickity is using a JavaScript-driven requestAnimationFrame animation. Let's not dive too far into that here, though, to keep this bug relatively focused; if you want to investigate that difference more, maybe we can do so over on bug 1894842?)

Please consider whether it might work to deliver the desired layout.frame_rate to the user but lie to the website about the frame rate.

We can't exactly lie to the website about the frame rate -- it's just something that web sites can directly observe. They can schedule JavaScript to run on every repaint, using the requestAnimationFrame API, and then measure how much time passes between those repaints. (We could in theory still run requestAnimationFrame JS at 60 FPS but only paint every 10th frame for example; but that might cause other site breakage, and it's not really robust since sites have other ways of measuring repaint speed as well. In any case, it'd be a lot of additional complexity in support of a not-really-supported about:config preference that's kinda only meant for TorBrowser.)

Confirmed resistFingerprinting was (repeat was, I've reset it based on your comments) true.

RFP doesn't permit overrides, but if you want to use RFP-level Fingerprinting Protections with an override for this specific one, you can do:

  • privacy.fingerprintingProtection = true
  • privacy.fingerprintingProtection.overrides = +AllTargets,-FrameRate

Aha, thanks!

This might be INVALID then, since things are working as-intended (with rFp not permitting overrides but fpP providing this same functionality with per feature overrides available).

Not quite the same behavior. I have Firefox set to reopen windows from the last session. If I have resized a window and closed and reopened Firefox, then:

With privacy.resistFingerprinting set to true:

Actual result: All windows are resized to the standard width.

With

privacy.resistFingerprinting set to false
privacy.fingerprintingProtection set to true
privacy.fingerprintingProtection.overrides set to +AllTargets,-FrameRate

Actual result: All windows are reopened at the same size they were when I closed Firefox.

This may be a separate bug if that is not the intended result.

That window sizing behavior seems to come from here or similar:
https://searchfox.org/mozilla-central/rev/1f46481d6c16f27c989e72b898fd1fddce9f445f/toolkit/components/windowwatcher/nsWindowWatcher.cpp#2320-2327,2345,2349

if (aSizeSpec.SizeSpecified()) {
  if (!nsContentUtils::ShouldResistFingerprinting(
          "When RFP is enabled, we unconditionally round new window "
          "sizes. The code paths that create new windows are "
          "complicated, and this is a conservative behavior to avoid "
          "exempting something that shouldn't be. It also presents a "
          "uniform behavior for something that's very browser-related.",
          RFPTarget::RoundWindowSize)) {
...
  } else {
...
    nsContentUtils::CalcRoundedWindowSizeForResistingFingerprinting(

Tom can perhaps comment on whether fingerprintingProtection is meant to match resistFingerprinting on this window-sizing behavior when +AllTargets has been selected.

That does sound like a separate bug, please do file it - FPP with +AllTargets should be causing the RoundedWindowSize behavior.

Filed as [#1897590]

Tom, could you please assign severity / priority? Thanks

Flags: needinfo?(tom)

I agree this is invalid

Status: NEW → RESOLVED
Closed: 4 months ago
Flags: needinfo?(tom)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.