API hooks to detect if a third-party iframe/embed is compliant or not, so first-party apps can show provide fallback options

[aaudu-codaio]

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.

[johannhof]

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!

[aaudu-codaio]

Hi @johannhof,

When you say "programmatic hooks", what exactly would you like to learn about a third-party iframe?

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.

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.

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:

• Spending support cycles on things we already have the answer to.
• Taking a trust and reputation hit since people generally assume it's the first-party app with issues and open tickets with us versus starting from the third-party.
• Every new embed we hear about or people want to try needs a pass from us to confirm whether "it should work" or not.
• People reporting things or finding in testing requires they cross the inertia threshold to report (sometimes they just assume the first-party app doesn't work for anything), or you're aware of the third-party (we continue to learn of new third-party embeds).

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!

[johannhof]

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.