Remove privacy.dynamic_firstparty.use_site pref

Context: https://phabricator.services.mozilla.com/D219990?id=918150#inline-1238868

Ben, what is the plan here? You wrote in your reply that "handling it (port in site) makes the test_dfpi_with_ip_and_port_and_non_default_use_site fall apart. I'm just going to remove the *_non_default_use_site tests since we are removing their code coverage."

Does the last part mean that you intend to drop the privacy.dynamic_firstparty.use_site pref? I.e. to keep the current default (true) and drop the false path?

To reduce the maintenance burden (in the extension cookies API and elsewhere), I would be in favor of dropping support for privacy.dynamic_firstparty.use_site, but that would be a call from the Privacy team, not extensions.

That last part meant that the test does not have any coverage of the "correct" behavior when privacy.dynamic_firstparty.use_site=false.

I don't believe I would call it supported right now. It is false, has never been true, and has no control beyond about:config. :timhuang would have historic context on it, and be able to give authority to that answer.

The pref was added at the beginning of developing partitionKey because, for a short time, we didn't use the site for partitionKey during the development. Given that the pref has been set to false for alone time, we can drop the pref and use the site for partitionKey by default. It makes no sense to support non-site behavior for the partitionKey.

I have more historic context: the previous iteration, First Party Isolation was domain-based. This is still domain-based, as privacy.firstparty.isolate.use_site is still defaulting to false.

The later addition, dynamic First-Party Isolation initially used domains too, but switched to site, as Tim mentioned.

Tim - would you be okay with removing the privacy.dynamic_firstparty.use_site pref? That would enable simplification of the extension cookie internals since it doesn't need to account for the unsupported pref.

Yes, I am fine with removing the privacy.dynamic_firstparty.use_site pref.

We should then just remove this pref and remove the tests dependent on this pref.

Although the initial trigger for this bug is an extension unit test, the majority of the affected tests are in the antitracking component, with some of the implementation in OriginAttributes.cpp, CookieJarSettings.cpp, so I'm moving this bug there for further triage.

Hi there, I'm a new contributor and would like to work on this if possible. Let me know if I can be assigned, thanks!

Thanks for being interested in contributing to Firefox.

Sure, I will assign this bug to you, and we are happy to help you finish it.