Support for Partitioned cookies attribute

[giles-v]

Feature or enhancement

Proposal:

Chrome is phasing out support for Third Party Cookies in Q1 2024, and for several key use cases, the proposed solution is CHIPS (https://github.com/privacycg/CHIPS).

See Chrome's blogpost about these changes: https://developer.chrome.com/en/docs/privacy-sandbox/third-party-cookie-phase-out/#partitioned

Currently, cookies with the Partitioned attribute cannot be set from within the http.cookies library. I'm proposing that we add support for that attribute.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

Linked PRs

• gh-112713 : Add support for 'partitioned' attribute in http.cookies #112714

[giles-v]

Hey there @AlexWaygood, just a ping on this issue per the contributors guide -- this issue and the PR have been up for about six weeks now. A review would be appreciated, thank you!

[Flecart]

I need this feature, for starlette. encode/starlette#2500.

[merwok]

AFAIU this is a proposed / experimental thing for now, and from MDN it’s not implemented in Firefox or Safari yet.
If this becomes a standard (with WHATWG or W3C), it could be considered for Python.

[merwok]

@gpshead could you reply to my note here before going on with the PR?

[gpshead]

Sorry I missed your comment earlier. Holding off awaiting a standard is fine, I misread it and thought it'd been implemented already rather than seeing those were the prior attempts.

This really just seems to be adding an attribute that adds an additional string to a cookie. If it winds up not meaning anything, it wouldn't be the end of the world - though we'd obviously need different docs than what the PR contains right now.

What's the alternative within the existing http.cookies API for adding Partitioned to a cookie it creates and checking for Partitioned when parsing today without implementing your own parsing? (that could expand into a bigger question about whether the stdlib API is actually a good one)

[Flecart]

I would like to note that https://developers.google.com/privacy-sandbox/3pcd#report-issues google is already rolling out this change for 1% of users.

[mst-kialo]

We had to patch in support for partitioned cookies ourselves in preparation for the switch to partitioned cookies in Edge / Chrome because that will likely be coming for every Chrome and Edge users no matter what. For us that makes the experience of users in embedded contexts much smoother since we know that we will be supporting embedding even after the phaseout of 3rd party cookies has been completed sometime this year on those two browsers.

It would be nice not having to patch it because the accepted attributes for morsels are as restrictive as they currently are, especially since unknown properties are simply ignored by other browsers. Firefox and Safari don't care if the Partitioned property is set and continue working with the cookies as is.

In conclusion waiting for this PR to be pulled until this has become a standard results in either a worse experience for users of chromium browsers or having to manually patch it in anyway.
Furthermore Safari and Firefox seem to have positioned themselves open to implement support for it sometime down the road as well:

WebKit/standards-positions#50
mozilla/standards-positions#678

[merwok]

OK, there seems to be consensus, so this can be added to 3.13

[picnixz]

FTR: issues with type-feature always target the latest branch.

[merwok]

ok but why remove the tag indicating the version that a feature will or does appear in?

[picnixz]

I think it's because the feature may or may not be included in that version when it's being merged. (Actually, I'm only following the devguide: https://devguide.python.org/triage/labels/#type-labels). We however use the 3.x labels for indicating the versions being affected by bugs (and those labels are then mirrored on the PR with "need backport 3.x")