Support partitioned cookie attribute for browser extensions
Categories
(Core :: Privacy: Anti-Tracking, task)
Tracking
()
People
(Reporter: timhuang, Unassigned)
References
(Blocks 1 open bug)
Details
https://github.com/privacycg/CHIPS#browser-extensions
Allow browser extensions to modify or set the partition key of the partitioned cookies.
|
||
Comment 1•5 months ago
|
||
Copying from my review at https://phabricator.services.mozilla.com/D198985?id=814938#inline-1108527
Whether the cookie partitioned is already implied by the existence of the partitionKey property (in the schema, see above). See also https://searchfox.org/mozilla-central/rev/3c72de9280ec57dc55c24886c6334d9e340500e8/toolkit/components/extensions/parent/ext-cookies.js#35-53
FYI: I have been involved with extension API design and CHIPS at a very early level (https://github.com/privacycg/CHIPS/issues/6), with the implementation currently being adopted by Chrome as well. I'm concerned if the current API design is not insufficient for the adoption of the partitioned concept.
I introduced the WebExtension API to support dynamic first-party isolation in bug 1669716, which is the underlying storage mechanism for partitioned cookies. Chrome has adopted Firefox's extension API implementation in https://chromium.googlesource.com/chromium/src/+/45052d18b0f8dd0eb1a7492dc92acb8ba96aff64
In my understanding, the Partitioned cookie attribute enables websites to opt in to dFPI regardless of whether dFPI is enabled. Is this true? If so, then there is no need to make any more changes to the cookies extension API, because the question "is the cookie partitioned" can be answered by "is the partitionKey property present"?
|
||
Comment 2•5 months ago
|
||
I think you are right here. The presence or absence of the partition key will be sufficient to determine if the cookie was partitioned in the cookie API.
The only possible change that may be coming to the cookies extension API is the addition of another field to the partitionKey, specifically to support the "ancestor bit". CHIPS is currently aiming to unify their partition keying with other Storages (and the current definition of SameSite for cookies) by adding a "same-site ancestor chain" bit to the partition key. That way a Site A iframe embedded in a Site B iframe in Site A has access to a different partition than it would if embedded directly in Site A.
|
|
||
Comment 3•5 months ago
|
||
In my understanding, the Partitioned cookie attribute enables websites to opt in to dFPI regardless of whether dFPI is enabled. Is this true?
Yes. This allows us to disable dFPI as well, effectively making partitioned cookies a server-opt-in rather than a user-pref-opt-out.
|
|
||
Comment 4•5 months ago
|
||
(In reply to Benjamin VanderSloot [:bvandersloot] from comment #2)
The only possible change that may be coming to the cookies extension API is the addition of another field to the
partitionKey, specifically to support the "ancestor bit". CHIPS is currently aiming to unify their partition keying with other Storages (and the current definition of SameSite for cookies) by adding a "same-site ancestor chain" bit to the partition key. That way a Site A iframe embedded in a Site B iframe in Site A has access to a different partition than it would if embedded directly in Site A.
Please ping me when the question of the extension API design becomes relevant. Then I will coordinate the API design with other browser vendors.
|
|
||
Comment 5•5 months ago
|
||
Given that Chrome just committed to rekeying in the past month and we agree, now isn't a bad time. (https://github.com/privacycg/CHIPS/issues/40#issuecomment-1883726735)
Apple seems to agree, as much as they think CHIPS is worth doing.
Description
•