Since Firefox 66, the anti-tracking project has been working on strategies to protect users against trackers. One of the solutions is the ‘cookie blocking for 3rd party trackers’. This is currently done denying 3rd party trackers access to their cookie jar (no cookies sent/received, no localStorage, IndexedDB, BroadcastChannel, etc).
As experience has shown blocking is not always the best path forward because blocking of legitimate requests breaks current web architecture. Hence, instead of blocking, we would like our tracking algorithm to be smarter and hence we would like to partition the cookie jar. To that end bug 1536411 decouples the nsIPrincipal to be used for the cookie jar and the nsIPrincipal to be used for anything else (networking, window and workers communications, and so on). The nsIPrincipal for the cookie jar is now called ‘StoragePrincipal’ and it can be obtained from the Document, from the WorkerPrivate, or from the nsIScriptObjectPrincipal and it can be created from an nsIChannel by nsIScriptSecurityManager::getChannelResultStoragePrincipal(). Normally, these getters return the regular nsIPrincipal of the resource. If the nsIChannel is classified by the URL-Classifier as a 3rd party tracking resource then its StoragePrincipal will be a modified nsIPrincipal - which is the ‘regular’ nsIPrincipal plus “First Party Isolation” (FPI) - See below the differences between FPI and StoragePrincipal. More technical, its OriginAttributes.firstPartyDomain attribute within the nsIPrincipal will be set to the top-level domain. When a document is loaded, it takes the StoragePrincipal by its nsIChannel and it propagates it to any storage API, worker, and so on. Because of this, tracking resources will use a partitioned cookie jar, unique for their origins, in that first-party domain. Also SharedWorkers and BroadcastChannels use the StoragePrincipal to generate their ‘sharing’ keys in order to avoid the communication between partitioned and non-partitioned contexts. Everyone interested in reading code comments, I refer the reader to: https://searchfox.org/mozilla-central/rev/0376cbf447efa16922c550da3bfd783b916e35d3/toolkit/components/antitracking/StoragePrincipalHelper.h#10 When storage access permission is granted (see StorageAccess API [1] or the anti-tracking heuristic [2]), the StoragePrincipal getters will start returning the ‘regular’ nsIPrincipal and any storage components exposed to content, will be reset/recreated: they will behave like the first-party resource’s one. This behavior is observable to content because, for instance, the localStorage data before and after the permission will be different. But, also the current approach [3] is observable to content: localStorage throws exceptions before, and it works after. The new storage partitioning mechanism is controlled by the pref: privacy.storagePrincipal.enabledForTrackers, which is to false by default. Difference between FPI and StoragePrincipal: a. With storagePrincipal we have partitioned cookie jars just for tracking resources. FPI has partitioned cookie jars everywhere, double-keying any origin. b. StoragePrincipal doesn’t break window-to-window communications because the partitioning the partitioning happens at a cookie jar level and it’s not spread to the ‘regular’ nsIPrincipal. c. We can ‘revert’ this partitioning when needed (StorageAccess API). [1] https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API [2] https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy#Storage_access_grants [3] https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy#What_does_the_storage_access_policy_block _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
