Desktop browser tracking cookies criteria question

Continuing the discussion from Abolish irrelevant to privacy requirements:

My understanding is that the intent of this criteria was to include the behavior of Total Cookie Protection in Firefox, which is enabled by default, and blocks third-party cookies from being effective trackers. Especially because IIRC this criteria was added when TCP was added to Firefox.

Brave also has similar functionality announced around the same time.

However, as pointed out that is obviously not what the website says, and Firefox is not outright blocking third-party cookies from existing. Do we just want to clarify our criteria includes TCP, or do we want to do something else?

It is worth noting that Brave does actually block third-party cookies by default, so it is better than Firefox in that regard and meets our current criteria.

2 Likes

I vote for changing the criteria to “prevents cookies from accessing data unrelated to their site.” Analytical data has valid uses and shouldn’t be seen as evil, especially if you’re intentionally visiting a site. I also prefer this option as it leaves the criteria open ended in case any new methods of defeating third party cookies arise.

3 Likes

IMO, blocking all third-party cookies shouldn’t be mandatory when partitioning works, but this is also broken in Firefox when a site is added to the exceptions. :smiling_face_with_tear:

3 Likes

We can still give this some time if anyone has last minute objections, but in the meantime I’ll mark this as approved for a PR to be created because I can’t imagine any reason we’d not want to make this change.

It’s not very clear to me why this is an issue, if you’re adding a manual exception?

1 Like

A post was merged into an existing topic: Mention how per-site exceptions affect Firefox’s Total Cookie Protection

Something to be aware of, is that some browsers use heuristics to make exceptions for state partitioning, which can allow unpartitioned access. This is also the case for Firefox in its default state.

See State Partitioning - Privacy on the web | MDN

1 Like

I don’t think partitioning third-party cookies affects this use-case in the first place, and blocking third-party cookies would only have minimal impact on analytics (maybe they can’t determine whether the same visitor is returning, but can still track pageviews), so either way it should not be a problem.


If we change the criteria to…

Must partition or block third-party cookies by default

…since these heuristics are locked behind specific user actions (e.g. clicking a login button usually), I would probably argue that people are (implicitly) consenting to change the behavior for that specific website to non-default behavior, while the default behavior remains to partition these as expected.

So I don’t think we have to change the criteria, but we can add an info box along the lines of:

For web compatibility reasons, Firefox will dynamically grant unpartitioned access to third-party cookies for 30 days in certain scenarios which require user interaction. For example, if you click a Login with SSO button on a website, Firefox will grant the SSO provider storage access to the website you clicked that button on for 30 days.

You can disable this functionality and partition all third-party cookies, but we do not recommend doing so as this can cause websites to break, especially if you use SSO functionality. To do so, you can go to about:config, search for the following preferences, and set them to false:

  • privacy.restrict3rdpartystorage.heuristic.navigation
  • privacy.restrict3rdpartystorage.heuristic.opened_window_after_interaction

We could maybe also add this, but I’m more on the fence about this note since I think we generally like dFPI over FPI:

You can go even further by disabling web compatibility functionality entirely, which will disable the two dynamic heuristics above, SmartBlock, and manual anti-tracking exceptions made by Mozilla for some websites, but we do not recommend doing so because this will cause significant website breakage with little privacy gain compared to Mozilla’s dynamic approach. To do so, you can go to about:config, search for the following preference, and set it to false:

  • privacy.antitracking.enableWebcompat

Curiously, Mullvad Browser differs from Mozilla’s privacy.restrict3rdpartystorage.heuristic defaults here, maybe because they are on 140 ESR.

@ruihildt I wonder if you or Tor have considered not using ESR releases in Mullvad Browser, with the benefit for Tor Browser being that MB could serve as a place to validate new features before the next TB release, similar to Fedora and RHEL’s relationship? Of course there are some privacy risks and additional resources involved, so maybe not, but I’m just curious.

FPI is no longer maintained outside of Tor Browser.

https://blog.torproject.org/future-of-tor-browser-alpha/ There have been Tor/Mullvad alpha releases based on the rapid releases channel for a few months.

2 Likes

Well not literal FPI that only affected known trackers, but I mean you’re essentially disabling all the features that make dFPI dynamic if you disable webcompat.

Oh, I think I didn’t realize (or more likely just forgot) they were also doing this for Mullvad in addition to Tor. Neat.