[tbb-dev] Establishing RFP behavior norms

[Tom Ritter]

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-Behavior
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