-
Notifications
You must be signed in to change notification settings - Fork 3
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
Clarifying use case 1: 3P/site B triggers pop up #1
Comments
Hey @DavidScales , thanks for the question! Use cases 1a and 1b (if shipped) would apply to the above flow. To address the concerns:
|
Fantastic, thanks for the quick response and explanations. Some follow ups (and potentially silly questions as I haven't followed Chrome development much previously):
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
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! |
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. |
Gotcha, thanks Anton & Johann! |
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. |
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. |
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:
I believe part 1 is expected based on https://github.com/amaliev/3pcd-exemption-heuristics/blob/main/explainer.md#initiating-frame-for-popup-heuristic
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 |
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 farFor this particular three-legged use case, where site A embeds site B, and site B opens an IdP pop up:
|
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:
My use case looks like this:
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:
nintendo.de
andaccounts.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.
The text was updated successfully, but these errors were encountered: