7 ms·
Implement window.{alert, prompt, confirm} removal from cross-origin iframes
- akersten 5y agoThey've even eschewed the standard way to opt-in iframes to powerful, dangerous features like `alert` and `confirm` - you can't even `sandbox` the iframe to allow it. You have to enroll your website in a Chrome Origin Trial[0], which only lasts until December, and also requires you to create a Google account, agree to Google ToS, and you might be blessed with the ability for your perfectly-fine-before-Chromium-team-came-along web app to keep working. Who the hell is in charge over there, and what compels them to incessantly break the web? [0]: https://developer.chrome.com/origintrials/#/register_trial/2541156089743802369 https://developer.chrome.com/origintrials/#/register_trial/2...
- userbinator 5y agoWho the hell is in charge over there, and what compels them to incessantly break the web? Google has a vested interest in doing so, and change is their weapon; it keeps control of the web in their hands when no other organisation has enough brute force to keep up with their changes.
- bawolff 5y agoIdk why everyone jumps to these paranoid conspiracy theories - alert() box to trick people has been a thing for decades, and its super rare for it to be used legitly outside of debugging.
- akersten 5y agoHow 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.
- throwaway2048 5y agoplenty of ads are malicious, and if you want to use an adbroker its super hard to control or address
- deleted 5y ago[deleted]
- ehsankia 5y 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.
- svieira 5y agoSuch 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 https://twitter.com/KekitoF/status/1420220292429926400
- taf2 5y agoWhen 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...
- javajosh 5y ago> its super rare for it to be used legitly outside of debugging Simply false. This change broke several of my companies apps, and it broke Salesforce, and God knows what else. And it's not just a layout problem; it's material behavior which changed.
- cratermoon 5y ago> it broke Salesforce take 1: Salesforce is already a broken heap of fertilizer take 2: Hmm, didn't Google try and fail to acquire Salesforce?
- irrational 5y agoWho uses alert for debugging anymore?
- TeMPOraL 5y agoIt's not paranoid conspiracy theory, it's good ol' "fire and motion" - https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ https://www.joelonsoftware.com/2002/01/06/fire-and-motion/. Google is absolutely doing this with the web. Everyone else is too busy either trying to catch up with Chrome or react to unending stream of Google's proposed changes to web standards - which keeps them pinned down, and gives Google the freedom of movement, allowing them to direct the evolution of the web as a platform.
- gatlin 5y agoAnd I don't know why you have to smear beliefs that differ from yours and the people holding them as "paranoid conspiracy." You can present your case without name calling (if you have one).
- cratermoon 5y agoThat's the not the real complaint. The real issue is this: Opting out requires signing up with Google and become a customer of theirs: https://developer.chrome.com/origintrials/#/register_trial/2541156089743802369 https://developer.chrome.com/origintrials/#/register_trial/2...
- HWR_14 5y agoIn fairness, the constant change is because other organizations have the brute force to keep up. If everyone else gave up on a browser they would stop changing things.
- voidnullnil 5y agoThe entire web does this, not just Google. Alert is pure garbage and should not have made it past the 90s. Also, basic auth popups need to go too. Not sure why browsers would ever make those focus stealing in the first place. There should not be one single way for a web application to steal focus. The current workaround is to download a buggy ad blocker (last time I used chrome, just like firefox it has no way to turn popups off). Edit: I just remembered alert no longer steals focus on modern browsers (IIRC). But basic auth still does (at least on my 50 year old fork of firefox).
- dylan604 5y ago>(at least on my 50 year old fork of firefox). Since you're obviously from the future, can you give me tips on some stocks or sporting events to "invest"?
- habibur 5y agoThat's a way of saying "decades old". Not to count years literally.
- deleted 5y ago[deleted]
- sam0x17 5y agobasic auth is super useful for protecting staging sites, however.
- deleted 5y ago[deleted]
- skywhopper 5y agoGiven their current market share, they have no incentive to behave otherwise. They will do what they wish. And since it’s Google paying the bills, if it doesn’t harm Google’s business then it’s not a problem for them.
- judge2020 5y ago> perfectly-fine-before-Chromium-team-came-along web app Sorry, I think you misspelt "years of tech debt on the brink of collapse, only held together with prayers and the liberty provided by cross-origin iframes to do whatever they want to the parent window".
- ajsnigrutin 5y agoBut it works. And after, it wont.
- akersten 5y agoI'd encourage you to read some of the testimonials in the bug tracker - the applications this is breaking are not tech-debt-laden monstrosities, they're very simple examples like repl.it and educational coding websites where the IDE is hosted in an iframe and you can run your code in-browser. I can think of many more derelict features I'd have removed first if this was really about cleaning up code smells. And regardless of whether you think `window.alert` is a giant pile of tech debt: "we don't break userspace" is a mantra that web browser teams would benefit to heed.
- geofft 5y agoIt is a mantra that web browser teams heed. That's why the HTML living standard is the absolute mess it is. "We don't break userspace" is not an absolute rule, and has plenty of exceptions in practice, including security and things where no legitimate use case has been identified.
- deleted 5y ago[deleted]
- hitekker 5y agoLinus Torvald coined the phrase "We don't break userspace" and he has been less than nice to people who seek to undermine compatibility in the name of security: http://lkml.iu.edu/hypermail/linux/kernel/1711.2/01701.html http://lkml.iu.edu/hypermail/linux/kernel/1711.2/01701.html
- modshatereality 5y ago>Who the hell is in charge over there, and what compels them to incessantly break the web? What do you mean, the linked article is just a blank white page...
- deleted 5y ago[deleted]
- madeofpalk 5y ago> Who the hell is in charge over there, and what compels them to incessantly break the web? Well, to be fair, they went to the standards body and proposed it, and both Firefox and Webkit were in favour of the spec change.
- userbinator 5y agoand both Firefox and Webkit were in favour of the spec change. They could oppose, but then Google would just spread propaganda about how their browsers are "less secure" or whatever. There's really no choice for other browsers at this point. From the point of view of neutrality, the whole "origin trial" thing is seriously messed up. You are effectively having to ask for permission from one megacorp to treat your site differently from others in its browser.
- floatingatoll 5y agoTo try and restate this, in case I misunderstand: You believe that Apple and Mozilla are rubber-stamping anything Google asks for because they’re afraid of a Google marketing campaign. Have I accurately represented your beliefs?
- userbinator 5y agoThe situation is not so clear with Apple (but there is some evidence that it puts up at least some opposition: see hit-pieces like https://news.ycombinator.com/item?id=27968394 https://news.ycombinator.com/item?id=27968394 and note all the pro-Chrome/Google opinions there...) but Mozilla is funded by Google. ...and regardless of whether you're using Chrome, the immense power of Google's marketing abilities cannot be overstated. It is an ad company, after all. (If you're using Chrome, it's self-explanatory; if you're not, you should notice just how much you get "recommended" to.)
- floatingatoll 5y agoDefinitely report what you perceive as astroturfing to the mods using the footer Contact link; they will want to know more.
- ceejayoz 5y ago> We decided to disable this deprecation temporarily (for 2 weeks, until August 15, 2021) to provide more time for websites to address the issues caused by this change, or enroll affected origins in the origin trial. Most sites aren't even gonna find out about it in a two week period, let alone be able to fix it. (Side note: Google has broken the text selection on this page, at least in Firefox. Didn't try in Chrome. Copy/pasting a paragraph was a trial.)
- heavymark 5y agoCoping test seems to work fine in Chrome and Safari, so don't think Google broke anything in regards to text selection/copy/paste on the page.
- stronglikedan 5y agoWorks fine in Firefox, too.
- ceejayoz 5y agoNot for me on OSX. New FF profile to rule out extensions/settings; https://youtu.be/XGTyDQGTC4E https://youtu.be/XGTyDQGTC4E.
- akersten 5y agoSomething's definitely misbehaving in Firefox on the page. Using a mouse to highlight text in a comment and then trying to move the highlight to the next paragraph, the selection jumps to the first paragraph as soon as the cursor leaves the `span` of each paragraph. From a quick look at the DOM, I'd bet dollars to donuts it's the weird combination of custom WebComponents and the #shadow-root stuff and other various markup excess that they just didn't bother to test with Firefox. Whether it's a bug with Firefox itself and how these elements are handled, I guess would need some investigation. But if it were my web app, I'd probably just fix it instead of blaming the browser. Screen capture: https://imgur.com/RmoSZRB https://imgur.com/RmoSZRB
- elktea 5y agoWhat's a legit use for this?
- kkirsche 5y agoPenetration testing proof of concept XSS code. We commonly use alert to demo that it is executing code. Certainly there are other options, it’s just a common tool for many testers.
- bawolff 5y agoTrue, however when people pop an alert from a cross origin iframe for a bug bounty, 80% of the time they're pretending to be on the parent origin when they aren't and get sad when their report is rejected.
- IncludeSecurity 5y agohttps://portswigger.net/research/alert-is-dead-long-live-print https://portswigger.net/research/alert-is-dead-long-live-pri...
- bawolff 5y agoOccasionally people use it for print debugging... but realistically its 99% malvertising.
- merb 5y agorepl.it which uses an iframe and it might be good to showcase prompt
- TheRealPomax 5y agoIt'd hardly be even minor effort for the repl.it folks to just include a file in their sandbox loader that gives folks a normal, modern modal when some JS contains prompt() or confirm(). Remember: it's not about whether it's useful, it's about whether there isn't a better way to do it, because it's useful. In this case: yeah, absolute. There are way better ways.
- trangus_1985 5y agoThis makes a lot of sense, and is (IMO) a really great thing to do for users. IMO Cross Origin iframe alert/prompt should only be allowable with CSP rules explicitly permitting the cross origin iframe in the first place (in allowlist capacity). The amount of abuse this has seen and will see is a blight, especially on the average user. HOWEVER What the hell, Chrome? This timeline for a change of this magnitude is INSANE. The opt-out process is INSANE. Forcing developers to opt into a TOS just to address YOUR changes is INSANE. This is such a small issue to be flexing so massively on, more evidence that we need users (and embedded browsers!) to switch to Mozilla
- phillipseamore 5y agoSwitch to Mozilla? They are positive to this, and Webkit also. That is often the case, Chromium just has a faster turn-around then the others so usually are first to implement. The discussion about this started a year ago with the individual browsers and WHATWG. https://bugzilla.mozilla.org/show_bug.cgi?id=1624978 https://bugzilla.mozilla.org/show_bug.cgi?id=1624978
- irjustin 5y agoNot a suitable answer for website owners. Even if they literally asked all their customers to switch, end users won't.
- r00fus 5y agoThe issue isn't the cross origin alert change. It's the TOS required and opt-out process.
- zelon88 5y agoFrom the Google discussion on this change back in March, located here [1]..... > "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 first comment response reads..... > "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 next comment agrees..... > "I'd like to second that. A part of the reason we have our launch process is to evaluate interop risk, which requires engaging with other vendors to see if they'd follow our path. A spec PR would enable them (as well as the API owners) to evaluate what this change actually means and allow them to express their opinions on it. FWIW, I'd be surprised if they weren't supportive of this, assuming we prove that this change is web compatible." So here we see on full display Google acknowledge that they have enough market share to ignore other vendors, awknoledge that it is not in the web's best interest to do so, and yet somehow that part of the discussion was allowed to completely die out. So yeah, switch to Mozilla. The conversation they had on the topic was much more aligned with what I want to see from my supply chain than the conversation I saw over at Google. [1] https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXiBj3D6A/m/JtkdpDd1BAAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXi...
- Andrex 5y agoFrom a comment near the bottom of the page from "apb...@gmail.com": https://bugs.chromium.org/p/chromium/issues/detail?id=1065085#c66 https://bugs.chromium.org/p/chromium/issues/detail?id=106508... --- Regarding adding it to the sandbox attribute (which was my suggestion - I'm the guy that was quoted earlier in this issue, as well as the one raising a bit of a stink in whatwg/html) or to the allow attribute (which I'm not super familiar with) -- there seems to be some bigger ideological push going on behind the scenes with members of the WHATWG to push for the removal of any blocking methods in JavaScript. To quote from https://github.com/whatwg/html/issues/6897 https://github.com/whatwg/html/issues/6897 : > _In general all of the simple dialogs (alert(), prompt(), confirm(), and beforeunload) are deprecated and being removed slowly but surely from the web platform. They use trusted browser UI, which opens them up to abuse, and they block the event loop, which is not in keeping with the web's cooperative task model_ <opinion> In my opinion, the issue potential misuse of dialogs, which was long ago addressed by showing the source of the dialog in the dialog itself, has been resurrected as means to push forward the removal of any and all blocking calls from JavaScript -- not just in this case. Removing it from cross-origin iframes, I believe, is more meant to establish a precedent to justify the removal of these functions from the entire spec. </opinion>
- TheRealPomax 5y agoHere's waiting for when we finally rip out document.write because it's one of the most damaging functions to have been kept on life support "because we don't remove things from JS, it would break the internet". Except of course for all those times we already did by not "removing it from the spec", just either removing support in all browsers, or by changing the security policies so that "the code is still accepted" it just throws security errors and won't actually run.
- mdaniel 5y agoAs a counter-point to this, `document.write` is (currently) a render blocking action, and thus allows one to load assets without a bunch of `document.addEventListener("DOMContentReady", (ohgawd) => {})` business to ensure a `window.__whatever__` is initialized before 10 quadrillion megs of JS run Maybe in some pseudofuture there will be a less heinous way to schedule the order of JS evaluation, but until that future materializes, document.write is damn handy
- seba_dos1 5y ago...and window.alert is a blocking action, which allows you to display a message like "You lost! Your score: 1234 points" without having to build additional UI or adapt the loop of your game to be able to prevent game logic from continuing until the user clicks "ok" - which for jam games is damn handy ;)
- danShumway 5y agoThis is peak Chrome; what seems to be a reasonably good idea that's hampered because it was pushed out thoughtlessly without putting any serious effort into notifying the people affected or making sure that nothing else breaks, or making sure that it thoroughly solves the problem. The product owners at Chrome are smart, but they're careless and constantly break the web because they don't seem to have enough of a sense of gravitas or caution about what they're doing. From what I can tell, this isn't a terrible change -- at least at first glance, it seems to me like we should probably remove prompts/alerts eventually. Just... competently remove them, without breaking people's sites and then shaming them for not keeping up with Chrome's official blog. I also love the juxtaposition here between how careless Chrome is about things like web audio/URLs/extensions, and how careful they've been recently about privacy and anti-tracking proposals. Heaven forbid that we block 3rd-party cookies by default without first rolling out 3 different proposals[0][1][2] and having an extensive very public debate about how to replace them. Breaking web audio for nearly every interactive site on the web (including timers on Google's own search page) is one thing, but breaking ads? That would be irresponsible. [0]: https://developer.chrome.com/docs/privacy-sandbox/first-party-sets/ https://developer.chrome.com/docs/privacy-sandbox/first-part... [1]: https://developer.chrome.com/docs/privacy-sandbox/floc/ https://developer.chrome.com/docs/privacy-sandbox/floc/ [2]: https://developer.chrome.com/docs/privacy-sandbox/attribution-reporting/ https://developer.chrome.com/docs/privacy-sandbox/attributio...
- throw_m239339 5y ago> . The product owners at Chrome are smart, but they're careless and constantly break the web because they don't seem to have enough of a sense of gravitas or caution about what they're doing. Now imagine when Chrome has no competition whatsoever anymore, which will eventually happen. Google will control the web, at the very least on PC and Android, which is like 90% of the audience or something. They will take terrible, unilateral decisions because of their monopoly and "standards" will be as good as dead.
- deleted 5y ago[deleted]
- 5y ago
- billconan 5y agothis broke our chrome devtool plugin. They should have notified people before hand.
- graderjs 5y agoHaha i love the tone deaf, dontgiveashit responses of the chromium team, just trolling devs: [... Dev engages in paragraphs long rant detailing their intricate use case and why it's so essential not realizing the chrome team doesn't give a shit...] We implemented an origin trial to temporarily opt out from the blocking. Would this solve your concerns while you migrate your app? If so, please see ... But if it doesn't solve your concerns, guess yer fresh outta luck there, slick. but more practically I think the suggestions of developers for a sandbox attribute is a great idea and I don't understand the purpose of this change nor how it seems the community wasn't consulted. But I love how when the pushback from devs happens, it's like because the chrome team failed to anticipate these various valid use cases, they're not even going to acknowledge the dev sentiment as a real thing... Pretty weird dynamic obviously they don't care about consultation I wonder what really drives the development mission?
- graderjs 5y agoBut I also get the point of view of the chrome Dev team if it's something like they just choose to not deal with so much feedback from people. I do the same thing that's why I disable issues on my popular open source projects....
- joepie91_ 5y agoThe difference is that you - presumably - aren't the de facto steward of one of the most important open communication platforms on the planet that literal nation states rely on to function correctly, in addition to the general public.
- deleted 5y ago[deleted]
- pornel 5y agoThis could have been handled better: * Position and clip the alert box within bounds of the frame, so that it doesn't display anything that the frame couldn't do itself. * Don't make framed alerts steal focus, so that it also loses special behavior. * Ideally, provide some replacement like `await alert()` so that authors can migrate with minimal changes.
- Animats 5y agoHasn't Firefox been blocking cross-origin iframes for years?
- gzer0 5y ago"Microsoft Edge released 92.0.902.62 today which now re-allows the dialogs in cross domain iFrames. We are suggesting that our user base moves from Chrome to Edge. Hopefully Chrome can do the same soon." Is this the time to shine for our dear old friend?
- sloshnmosh 5y agoI’ve been tracking a massive mobile malvertising and drive-by malware download operatition for the last several months. The malvertising company is abusing a script found on GitHub called: “alerty” hXXps://github.com/undead2/alerty#readme
- arduinomancer 5y agoHonestly I always thought it was weird that popping up a native browser dialog was even a feature offered by browser JavaScript APIs in the first place. Isn't the DOM the API for controlling anything visual? If that feature never existed and someone proposed it today there's no way it would get added.
- fomine3 5y agoalert is also broken in other way. When triggered by onblur, it causes infinite loop. But the bug is marked as WontFix because "Chromium team highly recommends that you not use JavaScript dialogs". https://bugs.chromium.org/p/chromium/issues/detail?id=666205 https://bugs.chromium.org/p/chromium/issues/detail?id=666205 https://developers.google.com/web/updates/2017/03/dialogs-policy https://developers.google.com/web/updates/2017/03/dialogs-po...
- thehappypm 5y agoYeah, I kind of agree with them here, alert is such a massive anti-pattern that it's not worth anyone's time to fix nonsense edge cases
- wdb 5y agoChrome is more and more becoming the new Internet Explorer :(