While reviewing a patch today I came across the exact situation that I sketched out https://gitlab.torproject.org/tpo/applications/tor-browser-spec/-/wikis/RFP-... for, and I'd like to try to establish a consensus around it as we start landing more RFPTarget patches. This way I'm not going off an affecting the behavior of Tor Browser without getting input from you =)

Below follows a summary of the wiki page. Several of these are not how things are implemented today (usually things are implemented to be more conservative, and I am proposing relaxing things in some instances.)

Most of these are independent of each other, so hopefully they can be individually LGTM-ed or debated.

1) RFP does not override granted Site Permissions.

A user has proactively granted a permission, through the browser UI to do something. Respect it. In TBB these don't persist anyway.

2) RFP does NOT override a per-site setting (other than a permission) that the user has set. (e.g. Zoom Level)

I can only think of Zoom level for this one - but if there's some other per-site setting the user can set, proactively, respect it. Again, in TBB these don't persist. (Right now I think we do override site specific zoom...)

3) RFP _does_ override changes in the Browser Settings page.

We probably won't go through and meticulously try to address every one of these, but when the situation comes up, we will override these settings. For example, a default zoom level for all pages. Although I have to say, the more I think about this one... I'm not so convinced. There are a medium amount of these (I counted: Default Zoom, DNT, Colors, Fonts, Font Size, Language, Smooth Scrolling, Autoscrolling (not even sure what that is), pop-up blocking) and most of those are accessibility related. Maybe we shouldn't override them. (Or in an ideal world, we warn the user before they change them, but allow them to do so.)

4) RFP does NOT override prefs on about:config

Practically, we'll never find and address all of these. So should we try to do any? The User Agent override one is something that users have asked for for the longest time and we always said no. Are there some we want to override because they're so much more common; but not override by default?

5) If you've enabled RFP, using the ETP toggle will NOT exempt you from RFP. (Only from FPP)

Maybe someday it will, but for now, while this is being developed, this feels like a footgun. So I've implemented it as not applying to RFP. (Although it hasn't landed.) In Tor Browser, the ETP toggle isn't even available/visible so it doesn't matter too much...

X) The ETP toggle that exempts you from FPP propagates to all subframes.

Sorry, this one is how Firefox intends to implement it. I'm putting it here to contrast with...

6) The exemptedDomains pref (aka the other exemption technique besides the ETP toggle) does NOT propagate to subframes

This is the more conservative behavior. So that's how I've designed and implemented it. Maybe we don't want to do that in the long run, but for now, I think it's better to be conservative.

7) An individual RFP behavior (like timer precision) can typically be exempted on a page. The exceptions are behaviors that affect the user's interaction with the entire browser.

For example in Bug 1832598 we discuss smooth scrolling, and apply the behavior globally so users have a consistent scrolling experience.

8) We're punting on DevTools

Sometimes its exempted, sometimes its not, sometimes its System Principal, sometimes its not. Untangling this mess isn't a priority right now.

-tom