proposal: net/http: support partitioned cookies

[islishude]

Since Chrome drops support for SameSite=None cookies, aka third-party cookies, net/http package needs to add Partitioned field to the type Cookie, and add a deprecated message for SameSiteNoneMode

ref:

https://developer.chrome.com/docs/privacy-sandbox/third-party-cookie-phase-out/

[ianlancetaylor]

CC @neild @bradfitz

It would help a lot if you could say more about exactly what should change in the Go package. Thanks.

[islishude]

Sure, updated.

[gopherbot]

Change https://go.dev/cl/526435 mentions this issue: net/http: add paritioned attribute to cookie type

[neild]

We don't want a deprecation notice on SameSiteNoneMode. Browsers may not support it, but the net/http package should support sending SameSite=None if the user wants to.

Also, partitioned cookies use SameSite=None, so browsers haven't actually deprecated this value.

Adding a Partitioned field to http.Cookie seems reasonable:

type Cookie { // contains existing fields
  Partitioned bool
}

[islishude]

@neild I'm agree with you. my pr just adds a note for the SameSiteNoneMode.

[iamdlfl]

Any updates on this proposal? It would be useful for something I'm trying to work on.

[gregwebs]

What more needs to be done to have this proposal accepted? The associated commit explains the changes clearly.

[nightlyone]

Supporting the partitioned cookie attribute without actually implementing the cookie jar changes implementing the semantics of the partitioning this attribute signals sounds at least incomplete or even dangerous from a security perspective to me.

So a more complete proposal should outline the full semantics and amount of changes to implement the support. Not only the encoding and decoding, but also creating the key to address the cookie jar elements and storing as well as accessing them in http.Client.Jar to reap all the benefits of such cookies.

[islishude]

but also creating the key to address the cookie jar elements and storing as well as accessing them in http.Client.Jar to reap all the benefits of such cookies.

I can't understand why it's related to http.Client.Jar.

the cookies could be parsed by http.readSetCookies function

[gregwebs]

This proposal implements server-side support. Client-side support is intended for browsers to block cross-site tracking. It's unclear if this use case would be meaningful for a Go HTTP client. If someone made an end user web browser in Go there is a lot they would have to add on to the existing http client such as this and CORS.

[islishude]

I think it's not feasible to add it to http.Client.Jar.

In the example above where https://support.chat.example is embedded on https://retail.example, the top-level URL is https://retail.example. https://developer.chrome.com/docs/privacy-sandbox/chips/

there should no scenes like above in the go http client.