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

Should network state be keyed beyond the top-level site #1035

Open
annevk opened this issue Jun 9, 2020 · 8 comments
Open

Should network state be keyed beyond the top-level site #1035

annevk opened this issue Jun 9, 2020 · 8 comments
Labels
security/privacy security-tracker topic: http

Comments

@annevk
Copy link
Member

annevk commented Jun 9, 2020

See shivanigithub/http-cache-partitioning#2 and #943 for some background. Currently the (proposed) prose allows for an additional key, but doesn't define what it is.

@annevk annevk added security/privacy topic: http security-tracker labels Jun 9, 2020
@gsnedders
Copy link

gsnedders commented Sep 14, 2021

I think we want to continue to allow an additional implementation defined key; there are different trade-offs here and one can imagine features like Firefox/Safari's (Intelligent) Tracking Protection making different trade-offs here depending on setting. In principle this should be transparent, and I'm unaware of much breakage caused by different cache keying. One can also imagine different strategies being taken by different UAs in "private browsing mode".

cc @johnwilander

@annevk
Copy link
Member Author

annevk commented Sep 14, 2021

For this issue I'm mainly interested in whether we consider it a security issue or not. And whether Chrome's solution addresses that comprehensively or not. (And I guess there's also a question as to whether a comprehensive solution is needed or something is better than nothing at all.)

@MattMenke2
Copy link
Contributor

MattMenke2 commented Sep 14, 2021

The reason for additional keys is to protect spying across cross-site frames in the same tab, which is much more a security issue than a privacy one. Sites can coordinate to provide each other this information, if they want, but extracting it from other sites without their cooperation is a cross-site attack.

For the record, Chrome's solution is to use iframe site and an additional bit set for iframes - so an attacker can potentially figure out what's loaded in other frames / what other frames navigate to, but not what they're doing internally.

The potential issues with Chrome's scheme are around performance (If https://a.com loads https://b.com resources, which then populate an https://b.com iframe, we'd need a new set of https://b.com connections for the iframe), resource exhaustion, and potentially making certain resource exhaustion attacks marginally easier (e.g, can max out the socket pools with fewer domains).

@annevk
Copy link
Member Author

annevk commented Sep 22, 2021

So from shivanigithub/http-cache-partitioning#2 my best understanding is that Chrome uses

<top-frame-site, document-site>

as key for most network state, except for the HTTP cache where

<top-frame-site, document-site, is-iframe-navigation>

is used.

Per https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md it seems that @wanderview et al plan to use

<top-frame-site>

for service workers and storage in general.

Wouldn't that mean that if you adopt service workers and cache resources therein you have a vulnerability you previously did not?

@MattMenke2
Copy link
Contributor

MattMenke2 commented Sep 22, 2021

Do you mean SWs are more vulnerable than the non-SW behavior where they previously were not (which is true-ish, assuming SW's aren't currently more vulnerable than the non-SW case), or that SW's are more vulnerable than they previously were (which I don't think is the case?).

@annevk
Copy link
Member Author

annevk commented Sep 22, 2021

Yeah, I'm saying that if we were to consider this to be a security vulnerability the solution for service workers (storage) does not seem adequate. Websites that adopt service workers would become vulnerable to attacks this defends against.

@wanderview
Copy link
Member

wanderview commented Sep 22, 2021

Per https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md it seems that @wanderview et al plan to use

<top-frame-site>

I don't think that is accurate. The SW partitioning proposal would effectively key on <top-frame-site, document-site> where the document-site is equal to the service worker origin's site. This is enforced by service workers being same-origin to any controlled documents.

@wanderview
Copy link
Member

wanderview commented Sep 22, 2021

Service workers could carry the "iframe-navigation bit" forward through a pass-through fetch if we wanted to. Ideally this would be tied to the destination, but it could also be a separate flag.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
security/privacy security-tracker topic: http
Development

No branches or pull requests

4 participants