Hacker News new | ask | show | jobs
by ehsankia 1775 days ago
> 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.

1 comments

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