[akersten]

How often is it that you have a malicious iframe on your website being used to trick people though?

Why only remove it from iframe and not the entire browser if that is the concern?

Why was this concern not alleviated with better UI for the standard alert dialogs?

Alert dialogs and prompts are huge for accessibility - they're genuinely one of the best ways to get a screenreader's attention and have the user interact immediately with something. They are great for the web. They provide a standard interface and I think we should use them more often.

To me, this is Chromium team doing one of two things: (1) Trying to fix a security concern and instead of improving the UI so it's clear where the dialog is coming from, being lazy and just turning the feature off, or (2) Boiling the frog: remove dialogs from iframe, wait a while, then remove them from top-most with the rationale that "hey, they're already not supported in iframes" because they think dialogs are so Web 1.0

I don't like it either way. Just let me opt-in via `sandbox` like I do for other iframe features. Honestly, even that's rude to make website developers have to do, but at least we're not left high and dry.

I'll be irrationally angry if this all boils down to some UXD thinking that alert dialogs are "ugly" or something.

[ehsankia]

> How often is it that you have a malicious iframe on your website being used to trick people though?

Definitely more often than whatever hacky edge case websites relies on this behavior.

[svieira]

Such as a gaming website that hosts arbitrary JS games written to fit within a particular size limit? Code sample web IDEs that are designed to teach people how to code quickly? An iframed rich text editor? An embedded reporting widget that wants to remind users to save their changes before they navigate away on the parent page? An enterprise application that's using the strangler pattern to wall off greyfield parts of their application and those parts were written in 2004?

These are not common-use-cases-for-average-websites-on-the-net, but for web _apps_ where third-party `iframe` is the quickest way to real isolation between divergent code, iframes are pretty common. And `alert`, `confirm`, and `prompt` are not common in such code either, but when they are used they're often used in code paths that expect blocking behavior and are therefore definitely not amenable to alterations.

And the fact of the matter is that as the developer of a web application _I can still get this blocking behavior_. "All you need to do is have the parent and the child cooperate by sharing a TypedArray between the origins and use `Atomics.wait`" [1]. If by having the parent and the child cooperate I can get the blocking behavior, why not allow me to do it simply with a `sandbox` attribute, rather than having me publish a `@backcompat/alert` NPM module that both sides can pull in to polyfill a functioning `window.alert`?

[1]: https://twitter.com/KekitoF/status/1420220292429926400

[sbierwagen]

The only time I've seen alert boxes used is in XSS demos and attack ads that break the sandbox to spawn 1000 popups that they say the FBI is blackmailing me, and that I should send 0.5 bitcoin to this address now.

[dheera]

> How often is it that you have a malicious iframe on your website being used to trick people though?

This is one of the most common phishing vectors.

[taf2]

When chrome was new and fresh... they fixed the alert dialog... making it possible to escape the tab that popped the alert and even close it... this was real progress. Kind of see their point with iframe but feel it was rash to assume you can just disable a feature. Everything should be permission dialogs... IMO... So then you open a new web app from Fancy CRM or productivity tool and you get a dozen permission dialogs for that domain... fine... do it once and move on... instead you login to Fancy CRM or productivity tool and it's broken now...

[throwaway2048]

plenty of ads are malicious, and if you want to use an adbroker its super hard to control or address