Clarifying use case 1: 3P/site B triggers pop up

[DavidScales]

Hello, apologies if this isn't the appropriate forum for this question.

I'm hoping to clarify if the proposed changes in this document apply to my use case, which is tracked here.

In use case 1 (also called scenario A and B), there are two points of interest for me:

1. the top level, first-party site is described as "the opener document"
2. there are only two parties involved (site A and site B)

My use case looks like this:

1. The user starts their journey in site A (classroom.google.com):

2. After an interaction, a 3P iframe resource is loaded (DavePuzzle on localhost in this case):

3. The user needs to be signed into this 3P embed specifically via an Identity Provider (Google single sign on is the required IdP). If they aren't already signed in, they click the sign in button within the embed and this opens a pop up in a new top level context:

4. The user completes authentication and authorization and the OAuth callback returns the sign in token to the 3P in the top level context of the pop up before the pop up is closed. Now the iframe can access the session cookie that was set in that moment so the user is signed in within the embed:

Currently this flow is will break with 3P cookie deprecation; the iframe can't access the session cookie of the 3P in the top level context. I'm able to roughly maintain behavior using the Storage Access API, however I'm concerned with the UX there because of the data sharing consent prompt.

My general question is, does it seem like the proposed behaviors in this document would apply to my use case?

My concerns are:

1. This document describes the top level 1P site (classroom.google.com in my case) as opening the pop up, but in my case it's the 3P embed that's triggering the pop up (at least conceptually for me, perhaps at the browser level that's not an accurate description).
2. I have a sort of three-party (classroom, localhost/DavePuzzle, and google auth) arrangement rather than two party like nintendo.de and accounts.nintendo.com. I don't think this would be relevant to the browser/cookies but just flagging.

I'm hoping use case 1a applies the above flow and use case 1b applies when the user is already signed in in the top level context, enabling the user to skip from step 1 above to step 4 above.

[amaliev]

Hey @DavidScales , thanks for the question! Use cases 1a and 1b (if shipped) would apply to the above flow. To address the concerns:

1. The term "opener document" came from the Window's opener property. This grabs the top-level URL of the document that opened the pop-up, irrespective of which frame initiated the navigation.
2. We've previously considered limiting this heuristic to only apply when an iframe on the opener document matches the site of the pop-up. However, we found enough "three-party" examples similar to yours, that we decided not to look for the presence of such an iframe.

[DavidScales]

Fantastic, thanks for the quick response and explanations.

Some follow ups (and potentially silly questions as I haven't followed Chrome development much previously):

1. I see the Storage Access API is in "In developer trial (Behind a flag)" in Chrome 117, which is out now. Are you able to comment at all on when this API might be available by default in Chrome? (Happy to move this comment to the Storage Access repo if more appropriate).

I'm trying to read the Chrome feature status but honestly I don't really understand the UI... I see for Desktop that it's got a light bar for Dev Trial but also a dark blue bar for Shipping, and I'm not sure if those correspond to timelines or GA or what:

2. Similarly, do you have any sense of how likely the heuristics under consideration here are to make it into a GA Chrome release before the 1% 3P cookie deprecation targeted at Jan 1?

Stepping back, what I'm trying to assess is (A) ensuring that if I get all my partners to migrate to Storage Access API now, it'll actually be generally available to end users (no Chrome flags) before the 1%3PCD and (B) how much weight I can put into the heuristics approach as a potential short term solution (i.e., could my current partners skip migration, or is this change something that's only likely to benefit future partners).

Thanks again!

[johannhof]

Hi David, regarding the Storage Access API, we just updated the Intent to Ship thread with information that we're rolling out in M117 Desktop (as announced) and are currently at 1%. This means our ship target is M117 but of course there could be delays during the rollout.

For your second question, this is currently still an explainer and we can't commit to availability before the initial 1% target, but we'll share more information about our plans soon. Given that the heuristics are compatibility measures it seems desirable to target the eventual ship dates in a way that minimizes friction for affected users and sites.

[DavidScales]

Gotcha, thanks Anton & Johann!

[DavidScales]

I wanted to follow up here and clarify an additional detail for the three-party flow I've described.

In the explainer, case 1a requires a user interaction with the top level "site B" pop up.

If there's only two parties, site A (1P top level) and site B (3P embed), this make sense to me - the user needs to select their account / enter password on the site B top level pop up.

In a three-party case, the top level pop up is a completely separate third party; an Identity Provider (IdP) like Google, Microsoft, etc.

In this case, the user is typically only interacting with the IdP, not site B, in a top level context. For example, a standard "sign in with X" OAuth flow, the pop up goes straight to an IdP (e.g., accounts.google.com) where the user chooses and account / enters IdP password, and then is redirected in the pop up from the IdP to a URL on site B that simply receives an authentication token (as a query parameter) and then automatically closes the pop up. The user never really engages with site B. (You can kind of see this in my posted screenshots above - there's no site B in the pop up, but I can post a recording or something if its more clear)

My question is would this interaction satisfy the proposed browser heuristics, or would these flows need to be modified, for example to make the user click some arbitrary button in the pop up on site B to "count" the interaction?

I could imagine opening the pop up to an effectively no-op site B landing page with a button that redirects to the IdP, adding a step to what I see in SSO integrations today.

[rtarpine-google]

Sorry for joining this conversation so late.

Unfortunately I don't think the heuristics apply to the use case as described above. As you mentioned, the popup is for the IdP, when it's site B that wants to access its cookies when embedded on site A. You would need site A to open a popup for site B.

And we should clarify, if an iframe opens a popup then the heuristic doesn't apply – we consider the top-level site directly opening the popup an indication of that site's "consent" for the 3P site to be granted storage access. Only if site A directly opened a popup for site B, and the user interacted in that popup, would the heuristic apply.

[DavidScales]

Thanks Ryan. It's been a bit but just wanted to follow up for posterity as I'm seeing 3P cookie access allowed with "This cookie is allowed by third-party cookie phaseout heuristics" in the context where:

1. the embedded 3P (site B) is the iframe opener, not the top level site A
2. the user does not interact with the 3P in the pop up context, only with the IdP

I believe part 1 is expected based on https://github.com/amaliev/3pcd-exemption-heuristics/blob/main/explainer.md#initiating-frame-for-popup-heuristic

The popup heuristic (Scenarios A and B) is valid for a popup initiated by any frame on the opener, including a third-party iframe.

Part 2 I think is unexpected, and I am investigating if I've missed something and can follow up later if I learn something

cc @cfredric

[DavidScales]

Following up to explain the behavior I'm seeing in part 2 above:

For my SAA design, I have a fix-it journey for when the user is discovering the 3P for the first time in an embedded context (something we expect to happen in Classroom). In this case, the browser automatically rejects requestStorageAccess calls. This breaks SSO, but protects privacy overall / stops embeds from spamming access requests. My fix-it journey in these cases is to open a 3P no-op pop up that the user simply closes. This counts as a top level interaction, and so I can retry the SAA flow as intended.

It looks like a side effect of this fix, is that I'm also activating the browser 3PC heuristic. This is interesting, because it means that users who have used the 3P embed site organically in a top level context, will not run into this SAA hiccup, and thus not go through the fix-it flow with a 3P pop up interaction, and thus use SAA as expected. Users who are discovering the 3P site for the first time in the embed, and go through the fix-it flow, will actually not really be using SAA afterwards, and instead will get lumped into the heuristic coverage.

This may cause some confusion but TBD (definitely confused me when testing SAA).

TL;DR: so far

For this particular three-legged use case, where site A embeds site B, and site B opens an IdP pop up:

1. It's irrelevant whether site A or embed B opens the pop up.
2. The heuristics don't grant unpartitioned cookie access to embed B in general, but do grant unpartitioned cookie access to the IdP. However...
3. We would expect the heuristics to grant unpartioned cookie access to embed B in the sub cases where:
   A. The pop up opens to site B first, and the user interacts, before redirecting to the IdP.
   B. A different pop opens to site B, and the user interacts, unrelated to the SSO/IdP pop up flow. This will be remembered by the browser for N days and carry over to the SSO flow in the future.