Right now when you set
network.cookie.cookieBehavior to 5, we apply the ETP rules and additionally will partition cookies and storage/communications for sites in the third-party context if the ETP rules do not apply to them.
Here is the rough set of steps for this:
- Let's add a new boolean pref in this bug, e.g.
privacy.dynamic_firstparty.limitForeign, false by default. This can be done by adding an entry to StaticPrefList.yaml.
- We need to introduce this pref to
mozilla::net::CookieSettings object which implements the interface would receive the current pref value from here and will return true from
limitForeignContexts if cookie behavior is 3 or is 5 and our new pref is true.
- Replace this condition with checking whether
limitForeignContexts returns true.
This should be enough to implement the new behaviour. Now if you rebuild and set
network.cookie.cookieBehavior to 5 and
privacy.dynamic_firstparty.limitForeign to true, you should see a behaviour similar to WebKit.
We'd also need to have some tests for this. In https://searchfox.org/mozilla-central/source/toolkit/components/antitracking/test/browser we currently have a number of partitioning tests:
browser_subResourcesPartitioned.js. The last one tests third-party cookies in a top-level page, and that one should definitely be modified to add support for the new pref in. This link highlights the parts of the tests which I think would be modified if the test is run with the new pref turned on. I think you should modify the test to make
runTests() accept a second argument to state whether the new pref should be true or false and cover both cases in the test.
browser_partitionedCookies.js is a test that checks the partitioning of cookies in the third-party context. It uses this helper. I believe the subtests using
runPartitioningTestInNormalAndPrivateMode() are probably the interesting one to focus on here. These tests create three top-level pages from three origins, attempt to store three pieces of "data" in the "data backend" being tested in the third-party context (e.g. inside a 3rd-party cookie in this test) and then read them out to verify the three distinct values are properly stored and can be retrieved.
Right now as you can see the test just tries to store
["A", "B", "C"] and expects to read back
["A", "B", "C"]. With the new pref turned on, it should read back
["", "", ""] (I think). So we should extend the
partitionedstorage_head.js framework to allow passing in
extraPrefs as well as override the expectation data we expect to read back. This could all be done through adding more arguments to
More generally though it would be nice to verify that the rest of the
browser_partitioned* tests which all use the same mini-test frameworks continue to pass with the new pref being set to either true or false. So perhaps a better way to do this instead of special casing everything in
browser_partitionedCookies.js is to modify the
partitionedstorage_head.js to run each test twice, once with and once without the new pref set, and add just one argument to
runPartitioningTestInNormalAndPrivateMode() to say whether we're running the cookie backend tests (e.g.
testCategory, could be "cookies", "cache", "serviceworker", "indexeddb", etc.) and inside
partitionedstorage_head.js use the
testCategory argument to specialize our expectation value when
testCategory == "cookies". Doing things that way would give us a more comprehensive test coverage which is nicer.