Open Bug 1869975 Opened 2 years ago Updated 2 years ago

ya.media chat broken by partitioning, works in Safari

Categories

(Core :: Privacy: Anti-Tracking, defect, P3)

Product:
Core
Component:
Privacy: Anti-Tracking
Type:
defect

Tracking

()

People

(Reporter: dveditz, Unassigned)

Details

[moco-confidential for now as the developer wasn't sure this test server could be widely shared]

ya.media provides a chat service that powers the chat on several different client websites. This chat is broken by ETP (cookie partitioning), but isn't broken on Safari. According to console messages we do grant Storage Access to the auth domain (done in a pop-up), but that doesn't carry over to the requests that set up the chat itself: a JS file and a web socket that the client's site loads.

They couldn't get me a test login on an actual customer's site so they set up a demo site at https://yamedia.chat

There's an auth popup to auth.qa.ya.media that sets a YamBackendJwt cookie on the domain .qa.ya.media. Once that succeeds the "client" site creates their chat instance by loading https://chat.qa.ya.media/YamChatInitialization.js which sets up a web socket to wss://chat-backend.qa.ya.media/portal/?...stuff...

With tracking protection disabled the YamBackendJwt cookie is sent to both of those. When it's enabled then it isn't, because the one set by Auth is not partitioned. In Safari the cookies are sent, but I didn't dig into whether they were partitioned or not.

If our Heuristic didn't auto-grant 1st party access to the auth popup I think this would have worked, right? Would this be a situation where the proposed "partitioned" cookie attribute would have helped? Or is it a bug that requests to "chat." and "chat-backend." were not included in the unpartitioned status of "auth." even though it set a ".qa.ya.media" cookies usable by all three domains.

I didn't mention, but obviously this demo site works fine in Chrome, too. Safari seemed a more interesting comparison because I know they partition sometimes, but I'm not sure how to check if they did in this particular case.

It's because our popup heuristic grants storage access in a {site, origin} scope. The storage access is granted for auth.qa.ya.media, but not the chat.qa.ya.media. So, we won't send unpartitioned cookies to chat.qa.ya.media. In Safari's case, I believe they are using a {site, site} scope in their popup heuristic, so it works.

Ben, do you know if Safari is using {site, site} scope for their heuristics?

Flags: needinfo?(bvandersloot)

If that's what Safari's doing we should copy it because that's what sites are writing for.

Is there any way for this site to explicitly use the Storage Access API to make this work? Or does that give the same {site, origin} access as the hueristic?

Is the Storage Access spec ambiguous, and we and Safari grant different things? ({site, origin} vs {site, site} ) If that last is true that's a serious spec problem -- it should be specific on which to use and tested in WPT

Is there any way for the site to opt-out of the heuristic? If we didn't grant storage access to the auth popup then it would be partitioned and everything would work fine. [at least, I assume auxiliary browsing contexts must be partitioned. seems like a hole if not.] Google's proposed "partitioned" cookie attribute seems like it would fit the bill, but I don't know what y'all think of that proposal and how likely we might be to implement it.

unhiding: this test site was create expressly so we could talk about and inspect it without having to include anything sensitive

Group: mozilla-employee-confidential

Ben, do you know if Safari is using {site, site} scope for their heuristics?

Probably. They use site for everything.

Is there any way for this site to explicitly use the Storage Access API to make this work?

Yes, putting the authenticate button in an iframe from chat.qa.ya.media and calling document.requestStorageAccess() on click.

Is the Storage Access spec ambiguous, and we and Safari grant different things? ({site, origin} vs {site, site} )

No and yes. The heuristics are out-of-scope of the spec and are basically just overgrown webcompat measures. We are working to specify them in hopes of carving a common path among browsers to removing them.

Is there any way for the site to opt-out of the heuristic?

No, but maybe we should. @timhuang: do we think this is worthwhile?

Google's proposed "partitioned" cookie attribute seems like it would fit the bill, but I don't know what y'all think of that proposal and how likely we might be to implement it.

It depends on the definition of partitioned in an unpartitioned context (which is still being worked out). The proposal isn't harmful to privacy and seems like a good thing to implement for compat.

Flags: needinfo?(bvandersloot)

I interpreted the MDN docs as saying explicit calls to requestStorageAccess() grant access to same-site documents, not just same-origin. I found the spec confusing and I'm not sure I'm reading it correctly, but it looks like the spec says the same thing. If that's true then shouldn't our heuristics match and grant to the entire site?

Or does Storage Access only ever grant access to framed sites, when loaded from that frame, and never to other 3rd party resources? That can't be right, can it? A site might OAuth through a popup, but resources are often fetched from the main site. Especially when it's an API. Of course it would work if the site was completely partitioned and never asked for storage access, but our heuristic is overriding that.

Flags: needinfo?(bvandersloot)

Is there any way for the site to opt-out of the heuristic?

No, but maybe we should. @timhuang: do we think this is worthwhile?

It might be useful for sites to opt out of the heuristics, so I think it's worth supporting it. Given that we want to standardize the storage access heuristics, we should include this in the future discussion.

Side note: This is the explainer of Chrome's heuristics.

I interpreted the MDN docs as saying explicit calls to requestStorageAccess() grant access to same-site documents, not just same-origin. I found the spec confusing and I'm not sure I'm reading it correctly, but it looks like the spec says the same thing.

This is correct.

Or does Storage Access only ever grant access to framed sites, when loaded from that frame, and never to other 3rd party resources? That can't be right, can it? A site might OAuth through a popup, but resources are often fetched from the main site. Especially when it's an API. Of course it would work if the site was completely partitioned and never asked for storage access, but our heuristic is overriding that.

This is actually exactly right too. When we flipped over to per-frame requestStorageAccess we left the heuristics as per-page for this reason.

If that's true then shouldn't our heuristics match and grant to the entire site?

Because the heuristics are per-page still, I wanted to leave them as the more constrained (origin, site) keying. However it may be worth moving them to grant for the entire site for consistency sake. The heuristics are a mess that needs cleaning (and eventual removal).

Flags: needinfo?(bvandersloot)

We talked about this in a privacy team meeting and don't want to relax our heuristics further. This leaves three typical options for fixing this that match what we have seen other auth systems do.

  1. Move the popup to be same-origin with the resource you need access to as a third party. This makes the heuristic work as intended, and given that the auth subdomain is not being used to protect the JWT, this is probably fine.

  2. Shuffle a session token about. You have access to the unpartitioned cookie from auth.qa.ya.media in the https://yamedia.chat/ page. You can also navigate back to the https://yamedia.chat with your JWT from the popup before you close it.

  3. Use the Storage Access API. That means that the "click here to authenticate" button would need to be in an iframe that also opens the web socket. If you already have the permission, there is no need to render the button to re-request the permission. This is a bit of shoehorning that turns the auth system into an authenticated embed.

Severity: -- → S3
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.