Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

track "site for cookies" on requests and propagate in passthrough service workers #1332

Open
wanderview opened this issue Oct 14, 2021 · 4 comments

Comments

@wanderview
Copy link
Member

Forking this from #1321 where we are planning to propagate the origin field on requests when a service worker does evt.respondWith(fetch(evt.request)). In order for the correct SameSite cookies to be sent in some cases we also need to propagate the "site for cookies" from the original request.

For example, consider if A frames B1 and then B1 does window.open(B2). Without a service worker in play "site for cookies" would be empty because B1 has a cross-site ancestor. With a service worker, however, the service worker will have a "site for cookies" set to B (even if partitioning is implemented since B2 is not planned to be partitioned).

Note, when "site for cookies" is propagated, we may want to allow it when the propagation results in the same or a more restrictive "site for cookies". I'm not sure if there is a way for the service worker "site for cookies", but we probably don't want the initiator to relax that.

@annevk
Copy link
Member

annevk commented Oct 15, 2021

See #693, but let's keep this open for the service worker angle.

@wanderview
Copy link
Member Author

wanderview commented Nov 18, 2021

So it appears that I was confused about site-for-cookies for navigations. @sbingler has explained that this section:

https://tools.ietf.org/id/draft-ietf-httpbis-rfc6265bis-03.html#rfc.section.5.2.1

Says the site-for-cookies for a navigation is determined by the frame being targeted by the navigation. In the scenario above we are creating a top-level document, so the site-for-cookies will always be set. The initiator's site-for-cookies is not relevant here.

@annevk
Copy link
Member

annevk commented Nov 19, 2021

Isn't there still a problem with something like A1 -> B -> A2, and A2 is navigated to A3?

@annevk annevk reopened this Nov 19, 2021
@wanderview
Copy link
Member Author

wanderview commented Nov 19, 2021

That is solved by partitioning with the "ancestor chain bit". We can set site-for-cookies properly for the service worker context based on the information in the StorageKey. That is better than trying to plumb something through because it applies to all fetches and not just passthrough fetches.

Edit: Ancestor chain bit issue: privacycg/storage-partitioning#25

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants
@wanderview @annevk and others