Set `privacy.partition.network_state = false` until we evaluate dFPI

Even though privacy.partition.network_state.connection_with_proxy is still false there are code paths checking privacy.partition.network_state but not privacy.partition.network_state.connection_with_proxy. I think we should disable privacy.partition.network_state until we make sure we're good with privacy.partition.network_state.connection_with_proxy, or investigate #40123.

changed milestone to %Tor Browser: 10.0

mentioned in issue #40280 (closed)

added Doing label

Sounds good to me. I looked at the privacy.partition.network_state usage, and auditing it is very difficult. The (rough) summary of the behavior in Tor Browser is:

• Four (?) caches are isolated when this pref is set:
  • Font Cache
  • Image Cache
  • Stylesheet Cache
  • DNS PreFetch
• privacy.partition.network_state changes network behavior (via StoragePrincipalHelper::GetOriginAttributesForNetworkState):
  • Isolating DNS prefetching
    • DNS prefetch is not allowed when a proxy is configured, therefore not a problem for Tor Browser
  • The Image cache behavior and Font cache behavior are not change because we disable third-party cookies
    • The network state partitioning relies on the (associated) Storage Principal
  • The stylesheet loader uses the PartitionedPrincipal for partitioning the cache
    • If the below conclusion is correct that NodePrincipal and StoragePrincipal and PartitionedPrincipal are all the same, then Tor Browser is not affected.

From what I see, the Storage, Partitioned, and Node Principals should always be the same in Tor Browser, and this results in FPI - but confirming is difficult because the Principals are set in multiple ways.

The "partition key" is different than FPI when it is set by:

• CookieJarSettings::SetPartitionKey
• StoragePrincipalHelper::UpdateOriginAttributesForNetworkState
• StoragePrincipalHelper::ChooseOriginAttributes

CookieJarSettings use SetPartitionKey in relation to service workers, so Tor Browser isn't affected here.

StoragePrincipalHelper::ChooseOriginAttributes returns early when third-party cookies are denied, so Tor Browser isn't affected here.

StoragePrincipalHelper::UpdateOriginAttributesForNetworkState is the only place I see where Tor Browser sets the partition key. Unfortunately, the partition key uses site-based isolation (instead of only eTLD+1) because it checks privacy.dynamic.firstparty.use_site (which we did not disable). UpdateOriginAttributesForNetworkState is used by nsHttpHandler::SpeculativeConnectInternal.

Based on this analysis and the uncertainty involved we should flip the prefs and re-spin Android 10.0.9.

assigned to @gk and unassigned @acat

This landed with !110 (merged) on tor-browser-85.0-10.0-1 for our 10.0.9 release and I cherry-picked it onto tor-browser-85.0-10.5-1 (cbad6095) as well.

closed

mentioned in issue #40123

mentioned in merge request tor-browser-build!212 (closed)

mentioned in issue #40783 (closed)

mentioned in issue #41496 (closed)