Primary eng (and PM) emails
Eng: carl...@chromium.org, mea...@chromium.org
Summary
This is a proposal to disallow window.{alert, confirm, prompt} from a cross-origin iframe. Currently, Chrome allows iframes to trigger Javascript dialogs. Chrome shows “<URL> says ...” when the iframe is the same origin as the top frame, and “An embedded page on this page says...” when the iframe is cross-origin. The current user experience is confusing, and has previously led to spoofs where sites pretend the message comes from Chrome or a different website. Removing support for cross origin iframes’ ability to trigger the UI will not only prevent this kind of spoofing, but will also unblock further efforts to make the dialog more recognizable as part of the website rather than the browser.
Motivation
The current UI for JS dialogs (in general, not just for the cross-origin subframe case) is confusing, because the message looks like the browser’s own UI. This has led to spoofs (particularly with window.prompt) where sites pretend that a particular message is coming from Chrome (e.g. 1,2,3). Chrome mitigates these spoofs by prefacing the message with “<hostname> says...”. However, when these alerts are coming from a cross-origin iframe, the UI is even more confusing because Chrome tries to explain the dialog is not coming from the browser itself or the top level page. Given the low usage of cross-origin iframe JS dialogs, the fact that when JS dialogs are used they are generally not required for the site’s primary functionality, and the difficulty in explaining reliably where the dialog is coming from, we propose removing JS dialogs for cross-origin iframes. This will also unblock our ability to further simplify the dialog by removing the hostname indication and making the dialog more obviously a part of the page (and not the browser) by moving it to the center of the content area. These changes are blocked on removing cross-origin support for JS dialogs, since otherwise these subframes could pretend their dialog is coming from the parent page.
Interoperability and Compatibility Risk
We haven’t engaged with other browser vendors regarding this change yet, but plan to submit a spec change proposal once the change is approved for Chrome. Since PRs to the HTML spec require one more vendor to support (and none to oppose), we’ll reach out to other vendors before sending the PR.
The current spec allows for early return in all 3 algorithms that trigger JS dialogs (see step 3 in 1, 2, 3), so if Chrome early returns in the cross origin iframe case it will not be violating the current spec. That being said, if other browsers are on board with the change we’d prefer changing the spec so it requires early return in this case.
Current behavior in other browsers:
Edge: Same behavior as Chromium.
Firefox: Always shows the dialog in the content area, with no URL if the message is from the main frame site or a same-origin iframe; shows “The page at <iframe URL> says:...” when the message is from a cross-origin iframe.
Safari: Always shows the dialog in the content area, with no URL in any case.
Alternative implementation suggestion for web developers
An alternative is for the dialog to be triggered by the mainframe website. Another option is for the subframe to create its own UI showing the message instead of using window.{alert, confirm, prompt}. If common enough, libraries could provide a polyfill that implements alert/confirm/prompt as web content if called from a cross origin iframe.
Usage information from UseCounter
In total, around 0.009% of page loads would be affected by the removal. We believe that core functionality will not be severely degraded, since the ability for users to disable JS prompts means sites already can’t rely on JS dialogs to always be displayed.
Additionally, we will provide an enterprise policy to allow cross-origin iframe JS dialogs to mitigate the compatibility risk for enterprise usecases.
Entry on the feature dashboard
We are not adding a feature entry to the dashboard. Since this is a modification of a feature, JS dialogs will remain, but a special case of them will be removed.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABgKfUT5nARoK%3DBq2064qWd7kAEO%2BFO4UgSLJoA8c-m%3DcfYEQ%40mail.gmail.com.
This is a very exciting change, and I do hope it works out!
One general question: the two other blocking dialogs on the platform are the one triggered by the beforeunload event and window.print(). I believe we already ignore beforeunload for subframes, but do you know about plans for print()?
From: Carlos IL <carl...@chromium.org>
> We haven’t engaged with other browser vendors regarding this change yet, but plan to submit a spec change proposal once the change is approved for Chrome. Since PRs to the HTML spec require one more vendor to support (and none to oppose), we’ll reach out to other vendors before sending the PR.
Although the spirit is right, this isn't quite the correct approach procedurally. It's best to submit a specification pull request before any Intents are approved, to better help promote cross-vendor discussion, and allow the API owners to assess interop risk by looking at the spec (and accompanying web platform tests). The specification pull request doesn't have to be approved, but it should exist, so that there is a public record of what we are implementing at the level of detail of a full specification.
> The current spec allows for early return in all 3 algorithms that trigger JS dialogs (see step 3 in https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#dom-alert, https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#dom-confirm, https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#dom-prompt), so if Chrome early returns in the cross origin iframe case it will not be violating the current spec. That being said, if other browsers are on board with the change we’d prefer changing the spec so it requires early return in this case.
+1 to both the observation that this doesn't technically require any spec change, and to the intention to submit one anyway. It's always better to narrow the case of implementation-defined behavior if we can.
> An alternative is for the dialog to be triggered by the mainframe website. Another option is for the subframe to create its own UI showing the message instead of using window.{alert, confirm, prompt}. If common enough, libraries could provide a polyfill that implements alert/confirm/prompt as web content if called from a cross origin iframe.
In general using these dialogs at all is bad practice, and causes subpar user experience and performance because of how they block the main thread. So ideally web developers should switch to using a different UI, instead of alert/confirm/prompt on the parent frame.
One day (far in the future), maybe we can remove alert/confirm/prompt/beforeunload entirely. Incremental steps like this one are exciting.
> We are not adding a feature entry to the dashboard. Since this is a modification of a feature, JS dialogs will remain, but a special case of them will be removed.
It would be good to add a feature entry anyway, so that web developers (and others who monitor the feature dashboard, such as Chromium release blog post writers) are aware of the change.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MN2PR13MB36137FD51915AF2DA5E71725DFCE0%40MN2PR13MB3613.namprd13.prod.outlook.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABgKfUT5nARoK%3DBq2064qWd7kAEO%2BFO4UgSLJoA8c-m%3DcfYEQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3Dfsovub9WC%3D2S5%2BRJoG1QosBJ10cLLcOH1rRquq3XA31Q%40mail.gmail.com.
Other dialogs: Yes, I believe onbeforeunload is already blocked for this case.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABgKfW34qCM_dNsV8GVx6VxfXdFBtjAxKTt5R4Brzcj1EGY0A%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJUhtG8AThGD8zdTL77gRT4av%2BVPyq4C13S%3Dz9JrNq6vbzVSrg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DeJxy%2BQGJfPJzySYUk1FiVRsRFO0J2uYNiO7R3fqpDKMQ%40mail.gmail.com.
LGTM3
(My only concern would be enterprise and you have covered that with an enterprise policy)
/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjZPQCAug_EPJEZCG_kcqoOmgoBvkzJJ-nYKtn8gd%3Dw7Q%40mail.gmail.com.
Do not worry and focus on your work with strength. As you said, this is the best solution for a better internet, and if you have a solution, offer it to compensate the damage. Otherwise, I will do my best to find a solution with consultants. But we need some women, I hope you are patient. Make sure we do the right thingدر تاریخ جمعه ۱۴ مهٔ ۲۰۲۱، ۷:۰۷ Tim Glembin <tim.g...@gmail.com> نوشت:
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMsakZMXU4d03Y_xLH2ztXHZ_%2BJRMD2KDQ3QZAfFsh8JBhcv-g%40mail.gmail.com.
I did have a suggestion, which was if you could whitelist trusted domain names in the parent window.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMsakZNgtbmG%3DE7nvkbYjOsWgpTPQjAAvwQrtMpdtD9qkt6V4w%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d73e72d6-8510-466a-8ad0-61428a8a91dan%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_Xuqe1tCspMLrMAgp6SxUDo7mPc%2Bx63VFVPGyLtbZZ%2BA%40mail.gmail.com.
I’m less sure in this case that permissions policy is a good idea, unless it’s time-limited. We’re on a long, slow path to deprecate and remove window.alert/confirm/prompt and beforeunload handlers due to their role in user-hostile event loop pausing, as well as phishing and other abuse mechanisms. We’ve been successfully chipping away at them in various cases, e.g. background tabs, subframes with no user interaction, and now cross-origin subframes. Each step is hard-fought progress toward the eventual goal, and we should consider carefully whether we want to regress, even in an opt-in manner.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_Xuqe1tCspMLrMAgp6SxUDo7mPc%2Bx63VFVPGyLtbZZ%2BA%40mail.gmail.com.
Yeah, I think we have a good spectrum of options: no opt-in, enterprise policy opt-in, reverse origin trial, and permissions policy. In my opinion, in this case the discussion should be whether the existing enterprise policy opt-in was sufficient, or whether we should also deploy something like a reverse origin trial. Going all the way to permissions policy does not seem warranted, although I tend to agree it’ll be an important tool for things like sync XHR.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-XJn14Gy1SJ%2B6HNs%3DwAwfyBKHyThMHtYC1ThUUG05VfQ%40mail.gmail.com.
Adding a temporary reverse origin trial sounds ok with me. It is a bit late to merge the change in my opinion, so this does mean we will have to delay to M92 for the launch. The biggest cost from the delay might be developer confusion when they don't see the change, but I think that can be mitigated by keeping this thread and chromestatus updated.This is indeed behind a Finch flag, but we were planning to launch default on (and keep the flag as an emergency switch). Since there is still time to disable the flag in code, I think we should do that if we are delaying (and merge the reversal to 91), then re-enable when the origin policy is added.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/27c12307-f114-4f96-bf98-285a29422114n%40chromium.org.
var warn = false;
var error = false;
var message = "";
if(some error condition) {
error = true;
message += "\n - Fix error condition";
}
if(another error condition) {
error = true;
message += "\n - Fix other error condition";
}
if(warning condition) {
error = warning;