You're right about both issues. We reused the firstPartyDomain field in OriginAttributes mostly for simplicity but long term if this feature proves to be viable we should probably introduce a new OA field specifically to be used for it to avoid these types of problems. That being said, making it actually compatible with the existing FPI pref would be more work than that.
On Thu, Apr 25, 2019, 1:08 PM Tom Ritter, <t...@mozilla.com> wrote: > 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 > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
