2039931 - Update ContentBlocking::ShouldAllowAccessFor documentation on third party tracker cookie blocking

Status: NEW

(Core :: Privacy: Anti-Tracking, task, P3)

Description

[Manuel Bucher [:manuel]]

The comment of dom/base/nsGlobalWindowInner.cpp:4893-4898 is outdated since we switched from tracker-cookie blocking to relying on cookie partitioning:

// 3. Tracking protection (BEHAVIOR_REJECT_TRACKER and
// BEHAVIOR_REJECT_TRACKER_AND_PARTITION_FOREIGN) is in effect and
// IsThirdPartyTrackingResourceWindow() returned true and there wasn't a
// permission that allows it. This will return ePartitionTrackersOrDeny with
// a reason of STATE_COOKIES_BLOCKED_TRACKER or
// STATE_COOKIES_BLOCKED_SOCIALTRACKER.

Potentially revised comment:

ContentBlocking::ShouldAllowAccessFor will return false for 4 main
reasons.

1. Cookies are entirely blocked due to a per-origin permission
   (nsICookiePermission::ACCESS_DENY for the top-level principal or this
   window's principal) or the very broad BEHAVIOR_REJECT. This will return
   eDeny with a reason of STATE_COOKIES_BLOCKED_BY_PERMISSION or
   STATE_COOKIES_BLOCKED_ALL.

2. Third-party cookies are limited via BEHAVIOR_REJECT_FOREIGN and
   BEHAVIOR_LIMIT_FOREIGN and this is a third-party window. This will return
   eDeny with a reason of STATE_COOKIES_BLOCKED_FOREIGN.

3. Third-party cookies are partitioned with BEHAVIOR_PARTITION_FOREIGN
   is in effect and this is a third-party window (tracker or not). This will
   return ePartitionForeignOrDeny with a reason of STATE_COOKIES_PARTITIONED_FOREIGN.

4. (deprecated) Third-party cookies are disabled for trackers with
   BEHAVIOR_REJECT_TRACKER and IsThirdPartyTrackingResourceWindow() returned
   true and there wasn't a permission that allows it. This will return
   ePartitionTrackersOrDeny with a reason of STATE_COOKIES_BLOCKED_TRACKER or
   STATE_COOKIES_BLOCKED_SOCIALTRACKER.

In the 1st case, the user has explicitly indicated that they don't want
to allow any storage to the origin or all origins and so we throw an
error and deny access to SessionStorage. In the 2nd case, a legacy
decision reasoned that there's no harm in providing SessionStorage
because the information is not durable and cannot escape the current tab.
The rationale is similar for the 3rd and 4th cases.

I haven't fully investigated how the updated version of the comment would look like and would prefer doing this in a separate patch from Bug 1918337. Therefore opening this as a follow-up.