Proposal: Disallow cross-origin iframes usage of window.{alert, confirm, prompt}

[carlosjoan91]

There have been a few spoofs that use JS dialogs [1][2][3], and in response some browsers have tried to identify the site triggering the alert in the dialog. This however leads to confusing UI in which users are shown a URL that is seen nowhere else, or an attempt at explaining the dialog is not from the top level page nor the browser (e.g. Chrome uses "An embedded page on this page says:..").
Because of this, in Chrome we are considering removing support for cross-origin iframes to trigger JS dialogs (link to Intent to Remove discussion).
The spec allows early returning in all three cases (step 3 of [4][5][6]), but if other browsers are on board with a similar change, cross-origin iframes JS dialogs can be explicitly disallowed by adding an early return step before step 3 for the cross origin iframe case.

Chrome's use counter data says around 0.009% of page loads would be affected with this change (0.006% for alert, 0.003 for confirm and 0.00006 for prompt).

[TimothyGu]

_{Here's the link to the Intent to Remove that works outside Google: https://groups.google.com/a/chromium.org/d/msg/blink-dev/hTOXiBj3D6A/JtkdpDd1BAAJ}

[annevk]

Could you clarify the exact origin check in use here? Is it same origin or same origin-domain (or even same site)?

[carlosjoan91]

The plan is for the check to be same origin. In Chrome that is the boundary we use to decide if we can allow the frame to trigger dialogs that look indistinguishable from top-level triggered ones.

That being said, feedback is welcome if folks think there are good reasons to go with same site or same domain instead.

[annevk]

A same origin comparison between the environment's origin and top-level origin seems reasonable to me. Pretty sure Firefox would follow if this is successful.

@cdumez thoughts for WebKit?

[domenic]

Same origin-domain (note: not same domain) would make the most sense to me, since if you're same-origin domain then you could just do top.alert() to get around a strict same-origin restriction.

[carlosjoan91]

Yeah, that's a good point, using origin-domain makes sense to match the boundary for top.alert().

[annevk]

Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1624978.

[manoharreddyporeddy]

Any update on this thread. It is in open for 8 months now. Thank you
Came from googlecolab/colabtools#888

[carlosjoan91]

We're still planning to do this in Chrome, and since Mozilla is also considering the change, I'll go ahead and put together a pull request while we hear from Webkit.

@cdumez: please let me know if there are any objections or thoughts from Webkit. Thanks.

[cdumez]

We're still planning to do this in Chrome, and since Mozilla is also considering the change, I'll go ahead and put together a pull request while we hear from Webkit.

@cdumez: please let me know if there are any objections or thoughts from Webkit. Thanks.

Seems like a good change.

[carlosjoan91]

I created a PR for the change, I'll send it for review once I write a WPT.

[cdumez]

Hi, I'd like to ask for some clarification with regards to iframes with sandbox="allow-modals". For example:
<iframe sandbox="allow-scripts allow-modals" src="doAlert.html"></iframe>

It appears this no longer allows doAlert.html to call alert(). This can be worked around by adding allow-same-origin to the sandbox directives:
<iframe sandbox="allow-scripts allow-modals allow-same-origin" src="resources/sandboxed-iframe-ALLOWED-modals-iframe.html"></iframe>

Is this as intended?

[domenic]

@cdumez great catch. IMO that is working as intended, as a natural consequence of this specification and also as part of the general clampdown on alert/confirm/prompt. However, I'm not sure @carlosjoan91 or @annevk were aware of that consequence while we made this change, so let's reopen and get their opinions.

Also, even if we affirm that this is intended, we should add a non-normative note to the spec explaining that allow-modals only works when combined with allow-same-origin, to explain the situation. So we can use this reopened issue to track that.

[carlosjoan91]

Good point! Wasn't aware before, but I agree that this seems to be working as intended after this change.

If there are no objections I can go ahead and add the note to allow-modals.

[annevk]

Sounds good to me, FWIW.

[kpeterson85]

We just encountered this change in Chrome beta 91.0.4472.19 and it has caused a couple of platforms to have issues. Will there be any controls around allowing dialogs to still be used from cross origin iframes?

One platform that is affected is Salesforce. In the native Salesforce UI they iframe content from different domains they manage for security reasons. In their iframed pages they will present confirm messages before an action can be taken. Now that the confirm is blocked, users are unable to move forward with the actions so different sections are unusable now.

A second platform that was affected is an online form builder we manage. Clients iframe our hosted forms (different domain) into their website. Normally when visitors click the submit button on an iframed form they receive an alert() if there were any field validation messages. But now when we click the submit button nothing happens because the alert() window is never shown.

I had not heard about this upcoming change and luckily use the beta and came across it. Will there be larger communication about this change so platforms can work on fixes before it arrives to the mainstream?

[addams-e-vizergy]

I have also noticed the issue mentioned by kpeterson85 with Adobe Experience Cloud on backend pages where iframes are used to manage Adobe Analytics. This update seems that it will be very impactful to many platforms that use iframes. Can this change be delayed or reverted so that providers will have adequate time to update applications to work for this significant change?

[carlosjoan91]

Thanks for reporting the issues. Since the issues seem to be more related with the timing of Chrome's launch rather than the spec change, I'd suggest we move the discussion to Chromium's bug tracker (there is already an open bug for this at: crbug.com/1204081).
If there are comments regarding the spec change, then those do belong here.

[shakti97]

I agree with @kpeterson85. Our product is also affected by this change. Some of the functionality stops working. Is there any workaround to allow this @carlosjoan91 for now, So we will have adequate time to adapt the change.

[kpeterson85]

@carlosjoan91 When I mentioned there being controls around allowing cross origin dialogs I was thinking about attributes on the iframe element. If dialogs are going to be disabled by default for cross origin iframes with the new spec then It would be helpful to give the parent page the ability to add something to the iframe indicating they should be allowed.

[carlosjoan91]

I can't speak for other browsers, but from Chrome, we would prefer not having an opt-out attribute. The reason we are planning this change is to make the UI easier to understand for users (and less abuse prone) by not having to explain the message is not coming from the site shown in the URL bar (or the browser itself), and having an opt-out means that case still needs to be handled. Also, there is an alternative for use cases as messages can be displayed in the site's UI instead of using a modal dialog.

[colonelpopcorn]

Hi All,
Appreciate all the work you all are doing to keep the web usable and safe! However, Chrome 92 broke our application and we are now looking at working into the weekend to update our application to accommodate this breaking change. While we're undoubtedly going to be better off for the changes, I'd like to know how you intend to notify regular users and developers of these changes in the future? Is there a status page we can watch to see what will be deprecated or do you expect web developers to follow w3c mailing/browser spec mailing lists? If the latter, do you have any suggestions on filtering out the signal from the noise? I realize this change was in the works for a year plus, but we were only made aware of the change after it broke our application. Please consider how to make developer experience better in the future, and please don't ever forget Hyrum's law.

Thanks,
Jonathan Ling

[taktikweb]

Following this thread! Chrome 92 broke our application too. Would love to hear about a workaround anytime soon.

[BLamy]

There is no right way to make this the default behavior without breaking a significant amount of the web.

I frame's should have to opt into this behavior by setting a property.