consider including a "cross-site ancestor chain" bit in the storage key

[wanderview]

Currently service workers have poor SameSite cookie protections because its "site for cookies" is simply set to the origin:

https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis#section-5.2.2.2

In contrast, documents take into account the top-level-site and the ancestor chain when computing "site for cookies":

https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis#section-5.2.1

This is problematic because it means adding a service worker to a site can reduce the safety of SameSite cookies.

With storage partitioning we have the opportunity to fix this. We already plan to include top-level site in the storage key which will allow us to include it in the "site for cookies" computation for service worker. We lack any ancestor chain information, however.

The ancestor chain is important for "site for cookies" because it helps protect against clickjacking attacks. To extend this protection to service workers we propose:

Include a "cross-site ancestor chain" bit in the storage key. This bit would be true if there are any sites between the current context and the top-level context that are cross-site to the current context. So it would be true for A -> B -> C or A -> B -> A. It would be false for A -> A or A -> B.

With this bit in the storage key it would permit us to compute a "site for cookies" value for service workers that is equivalent to any document controlled by that service worker.

This was discussed at the recent service worker virtual F2F: w3c/ServiceWorker#1604.

[annevk]

Just to be clear on the implications here:

1. Since it's part of the storage key, it would affect an entire storage shelf. I.e., service workers, localStorage, etc.
2. It would mean that documents that have synchronous script access (in A1 -> B -> A2, this would go for A1 and A2) no longer observe the same storage shelf so you have to be careful where you peek into storage.

The benefit of this is that sites can adopt service workers easily without ending up in a worse security situation. That makes me think it's worth it, despite the fact that 2 above is something I had been trying to avoid.

[wanderview]

Are there known use cases for synchronous scripting in this scenario? Could we look to make synchronous scripting also dependent on the cross-site entries in the ancestor chain?

[annevk]

In theory it's possible, but I'm not sure what the compat story for that is. Would it be a new agent cluster essentially or something in between? (We'd also have to untangle the window name targeting algorithm presumably, but that needs solving anyway.)

[annevk]

In the last call @bvandersloot-mozilla mentioned Mozilla was in principle on board with this. @johnwilander has Apple looked at this?

A point that @johannhof brought up that I think is quite important is offering consistency to web developers. I don't think it would be a great outcome if storage is partitioned, but network and cookies are not. Ideally we offer the same boundary across the board.

[wanderview]

A point that @johannhof brought up that I think is quite important is offering consistency to web developers. I don't think it would be a great outcome if storage is partitioned, but network and cookies are not. Ideally we offer the same boundary across the board.

I agree with this in principle, but I've been told there are important use cases for cookies that make the situation different from other storage. I would also note cookies are already quite different from other storage in other ways. Expiration, quota, network transmission, etc. They also tend to be used for different use cases; auth vs stateful app logic, etc. While undesirable, it doesn't seem too extreme to diverge on this nuanced aspect of partitioning.