Feature request: Opt into origin-partitioned cookies

[fscottgaston]

While experimenting with CHIPS, I noticed that unlike the example provided at https://chips-site-a.glitch.me and https://chips-site-b.glitch.me, the partition key of the cookie does not include the hostname portion of our domain.

On this page, there a note stating:

It is recommended to use the __Host prefix when setting partitioned cookies to make them bound to the hostname (and not the registrable domain).

However, it seems to make no difference if I use the prefix or not.

Are there any other considerations that would prevent the hostname from being included in the partition key?

Thank you!

[johannhof]

Partitioned cookies are keyed by the top-level site. This does not affect the security guarantees of __Host, being that your cookie is valid for roughly the origin of the requestor, and will not be overriden using separate subdomains / paths. CHIPS used to require __Host to motivate better security on the web but that requirement was removed again, see #43.

Why do you think that in the above example the hostname is included in the partition key?

[johannhof]

Or maybe put differently, in your application, what makes you believe that __Host is not working correctly?

[fscottgaston]

The partition key for the cookie is displayed in the dev tools (Application -> Cookies). Go to chips-site-a, and view the partitioned cookie for chips-site-b. The Partition Key reads: "https://chips-site-a.glitch.me".

For my experiment, it would read "glitch.me" even when I use the __Host prefix (I am not actually using the same hostnames, I am only using them here to illustrate the point). The quote I sent above sounds like the prefix should resolve the issue. Though, the prefix may not be a possibility for me, I wanted to know if it resolves the issue. It seems it does not.

Although the glitch example doesn't clearly demonstrate this, I believe this could be a problem for my use case since both chips-site-a and chips-site-b have access to the chips-site-b cookie created when chips-site-a is the top-level domain. If you go back to the article and scroll to the What is CHIPS?: Partitioned section, the second figure would be violated, since both A and C sites share a domain and the partition key is using that domain only and not the hostname.

[fscottgaston]

The concern for our use case is if we have customers (A and B) using the same domain. A user for customer A goes to their site, cust-a.example.com, and obtains a partitioned cookie for our service (separate domain). If that user then navigates to cust-b.example.com, they will be able to use that same partitioned cookie since the partition key is only matching example.com at the top-level. (Which is a violation of the first figure in the What is CHIPS?: Partitioned section.)

[johannhof]

Cookies are always partitioned by top-level site, which is scheme + registrable domain, e.g. https://example.com. However, in the Glitch example, the top-level site is https://chips-site-a.glitch.me because glitch.me is on the PSL for security reasons (doesn't want to allow sharing cookies between its subdomains). So, yes, it is a bit misleading in that instance but unfortunately it's hard to host these examples without this kind of protection.

Hostname-bound cookies, on the other hand, do not affect the partition key. What __Host does is it prevents other hosts under your own registrable domain from overriding your cookie and thus potentially attacking you.

Unfortunately I think for your use case this means you'll have to find a solution that is tolerant of the partition sharing you described above. But I'm curious why this is a problem for you, until very recently CHIPS didn't exist at all, shouldn't your service already be used to third-party cookies being shared by default?

[fscottgaston]

@johannhof Thank you for the clarification! That explains what I am observing.

As for our current solution, the goal is to improve the current scheme. CHIPS may not get us there if this is a valid production concern (I have an inquiry to determine if this is possibly a case unique to our dev/test environments). If it is a production concern, then we need a different solution as you suggest.

[johannhof]

Ok, that's good to hear! With that resolved, we can either close this issue or you could change it to "Feature request: Opt into origin-partitioned cookies", which seems to be what you're looking for. To be clear I don't think this is something we'd consider doing right now, but it might help other developers add their support for the idea.

[fscottgaston]

Just an update on our specific situation. It does look like it is a valid concern for us and thus CHIPS will not be a valid long-term solution for us without a way to create origin-partitioned cookies. Thanks!

[annevk]

Are you specifically asking for a tighter partition?

Though if you have a a.example.com and b.example.com setup where a/b are not fully under your control, shouldn't example.com be registered as public suffix?

[fscottgaston]

Yes, the request is for a way to opt-in for the partition key to be set to the entire top-level hostname and not just the top-level domain.

Ideally, it would be nice if they were all registered. We don't control our customers domains, so I am not sure we can rely on all services that provide the sub-domains to register their domains as public suffixes.

[user8547]

Yes, let's create OriginPartitioned attribute for that.

Also, analogously would be nice to introduce SameOrigin cookie attribute in addition to SameSite.