If you have FPI enabled; it will override the StoragePrincipal switch and always return the partitioned jar; correct?
Also, I don't think this is a big problem; but users who have enabled FPI in the past and then disabled it will have pre-populated sub-cookie jars for the trackers. This will link a prior 'identity' to the current one. -tom On Mon, Apr 15, 2019 at 3:23 PM Andrea Marchesini <amarches...@mozilla.com> wrote: > > 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 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
