-
Notifications
You must be signed in to change notification settings - Fork 77
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
API hooks to detect if a third-party iframe/embed is compliant or not, so first-party apps can show provide fallback options #302
Comments
Hi @aaudu-codaio, I'd like to better understand what you're requesting here and why. When you say "programmatic hooks", what exactly would you like to learn about a third-party iframe? That it had cookies blocked? Note that, besides being problematic from a security perspective, this doesn't give you reliable information about user-facing breakage. Displaying prominent user-facing messages for pure 3PC-blocking events would be quite noisy and largely not actionable. I'd like to understand better why, as a 1P site owner, you would not be able to know which 3P embeds are broken from testing or user reports and give those the UI treatment you mention in this issue. Thanks! |
Hi @johannhof,
We'd like to programmatically know if the third-party moved the newer APIs / changes or not? We don't need to know which ones, just that we can quickly answer what may be causing issues a customer would report.
it's question of scale and support. We could do this and started from this position for our existing infrastructure. That said, some of the challenges we've seen:
Considering the amount of third-party experiences that could be an iframe, rather than rely on testing an ever expanding set or waiting for reports, if we can programmatically catch issues like this upfront, it gives us an opportunity to set expectations in the first-party experience accordingly. Any opportunity we have to reliably know of issues and provide any guidance — even if just, "Hey, you may see X and it's a known issue. Learn more.", our customers have found valuable. Please let me know what questions you have and many thanks for engaging! |
Thanks for the feedback, though I want to be clear that this sounds very difficult to do for a variety of reasons - one being that there's no clear indicator for whether a third party moved to a new API vs. not, another being that this kind of information is separated by the same-origin-policy and thus not available to the embedding party. |
Per Ben Kelly wanderview@chromium.org on Wed, 27 Mar 2024 at 15:03 filing here.
Expanding on Adam Gertenbach’s excellent feedback, we’re wondering what options we have as a first-party web app, in the likely scenario that a third-party app doesn’t update their iframe/embeds, and we’re past the deprecation trail (DT) period with third-party cookies phased out?
We’re concerned about the customer experience and reputation impact to our first-party app, hosting the third-party iframe. We’re hoping for some programmatic hooks or options we can leverage as a first-party, so we can provide some affordance to educate our customers.
For example, you could imagine similar to the Google new sign-in page notice or older Google chrome plug-in crash butter bar — see screenshots below, we show a similar notice for third-party iframes/embeds that are out of compliance or some other experience e.g., break glass, so we have an opportunity to customers and set expectations accordingly.
image.pngimage.png
We wanted to call out this scenario and see if we missed options here we can leverage as this feature rolls out to all chrome users.
The text was updated successfully, but these errors were encountered: