Re: Proposal for new `Partitioned` cookie attribute

Hey all,

We think we're now ready to start building consensus in this group to add
the Partitioned attribute into RFC6265bis (or RFC6265ter if appropriate).
Here's an I-D to get the discussion started:
https://datatracker.ietf.org/doc/draft-cutler-httpbis-partitioned-cookies/00/

Thanks,
Dylan

On Sun, May 9, 2021 at 10:08 PM Mark Nottingham <mnot@mnot.net> wrote:

> Hi Kaustubha,
>
> Thanks for bringing up a proposal. It doesn't appear that you're currently
> asking for adoption in RFC6265bis (which would be required to standardise
> it, since cookies don't allow independent extension), but FYI for when
> you're ready:
>
> The process that we've agreed to for RFC6265bis is that all proposals for
> new features and substantial changes need to go through a
> consensus-building process before they can be incorporated into the
> document.[1]
>
> For it to be considered, you'll need to write it up as an Internet-Draft
> (so that it has the appropriate IPR declarations, among other reasons). If
> necessary, we can get someone to help you with that.
>
> Then, we'll discuss it on-list, and optionally you can present something
> in one of our meetings. Provided that initial feedback is positive, we'll
> do a Call for Adoption; if the bar described in [1] is met, we'll take it
> on and the editors will start incorporating it into the document.
>
> Note that we don't recognise the WICG as having any weight in this process.
>
> Feel free to ask if you have any questions about the process, and if/when
> you're ready to move forward, please tell us.
>
> Cheers,
>
>
> 1. https://lists.w3.org/Archives/Public/ietf-http-wg/2015OctDec/0165.html
>
>
> > On 1 May 2021, at 2:31 am, Kaustubha Govind <kaustubhag@google.com>
> wrote:
> >
> > Hi all,
> >
> > I am part of the Chrome team working to phase-out third-party cookies;
> and would like to invite your feedback on our proposal to introduce a new
> `Partitioned` cookie attribute: https://github.com/DCtheTall/CHIPS
> >
> > While third-party (cross-domain) cookies enable tracking across the web,
> there are also use cases on the web today where cross-domain subresources
> require some notion of session or persistent state. In these scenarios, the
> intention for the cookies is not to track across sites, but to provide a
> notion of session (or state) to embedders for a user's activity within a
> single top-level context.
> >
> > Our proposal is to introduce a new opt-in cookie attribute,
> `Partitioned`, which servers can use to indicate they’d wish to set a
> cross-site cookie which is partitioned by top-level site.
> >
> > I should also point out that Firefox recently started partitioning all
> third-party cookies by default in the ETP Strict mode [1]. We prefer an
> opt-in approach to ensure that developers fully understand what semantics
> to expect, and avoid potential confusion and site compatibility issues. In
> addition, the WebKit team also recently proposed using the Storage Access
> API to allow embeds to optionally request access to partitioned cookies
> [2]. We think using a cookie attribute will be more efficient than a
> JavaScript-based approach.
> >
> > The motivation for this work is that when major browsers no longer
> support unpartitioned third-party cookies, these Partitioned cookies should
> not be subject to the same cross-site cookie restrictions as unpartitioned
> third-party cookies. This would allow third parties to continue to use
> cookies without giving them the capability of storing cross-site
> identifiers on users’ machines.
> >
> > We understand that this attribute will likely not be applicable to all
> HTTP clients. At this time, we would like to incubate the idea in the WICG
> and are asking for feedback/support here:
> https://discourse.wicg.io/t/proposal-cookies-having-independent-partitioned-state-chips/5290
> >
> > Thank you,
> > Kaustubha Govind
> > Engineering Manager, Chrome
> >
> > [1] https://hacks.mozilla.org/2021/02/introducing-state-partitioning/
> > [2] https://github.com/privacycg/storage-access/issues/75
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>