Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Implement window.{alert, prompt, confirm} removal from cross-origin iframes

bugs.chromium.org

Post reply on HN
Print view View original

31–40 of 160 posts

Re: Implement window.{alert, prompt, confirm} removal from cross-origin iframes

#31

Post by masswerk »

jdmichal wrote: post #22
elktea wrote: post #7

What's a legit use for this?

Examples from TFA: * Web-based REPL or IDE environments, where the iframe is typically the primary user interaction space. * Paid third-party website embedded into an internal website. * Hosted JS content such as Kongregate games. * Frames wrapping older webapps as part of an evolutionary uplift plan.

So everybody has to write or to add some kind of UI-kit and use async-await or callbacks. The loss of a blocking state for that particular thread is in practice the only result of this (besides breaking a lot of backward compatibility).

However, the loss of system dialogs in favor for custom UI-kits implemented in the DOM is a major attack on accessibility.

Edit, regarding backward compatibility: A sustainable web-stack is really of major concern. For some decades now, most of human creativity and content production has been published on the Web, much of this exclusively so. Backward compatibility is important, if we don't want to leave a singular black hole as our legacy and as the heritage of future generations. For us as a society, as a culture, this is of much more importance than adding yet another fancy capability to the standard. – As it turns out, the singularity is not artificial superintelligence (ASI), but the evergreen browser and rolling web standards (EGB-RWS).

Re: Implement window.{alert, prompt, confirm} removal from cross-origin iframes

#32

Post by geofft »

akersten wrote: post #27
judge2020 wrote: post #18

Earlier quoted context omitted.

> 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".

I'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 regard…

It 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.

Re: Implement window.{alert, prompt, confirm} removal from cross-origin iframes

#33

Post by modshatereality »

akersten wrote: post #2

They'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-c…

>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...

Re: Implement window.{alert, prompt, confirm} removal from cross-origin iframes

#34

Post by asdfasgasdgasdg »

trangus_1985 wrote: post #13

This 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 INSA…

What's insane about the timeline? They started talking about this a year and a half ago, approved it winter this year, and had it out in beta in May. How much longer should they take?

What's insane about the opt-out process? It seems very easy to me. I was able to generate an opt-out token in about three minutes for example.com. I'm a backend developer so I don't know too much about web servers, but I imagine it would take another ten minutes for an experienced person to make a commit that adds the reverse origin trial header to the default headers for their servers, possibly as a cherry pick to their existing release.

What's weird about the TOS? It's just the Google standard TOS, which you have to abide by using google.com or any other Google web property. 99.99% of possible interested developers are already covered by it, right? There is no way Google could offer you a service like this, or even documentation for it, without some kind of terms of service.

R.e. switching to Firefox, sure, browser diversity is great, but that won't affect anyone who uses your web site. They'll still be on Chrome or Safari, so this type of thing is still going to be something you have to handle. And anyway I guess that Mozilla will probably remove this option before too long as well.

Re: Implement window.{alert, prompt, confirm} removal from cross-origin iframes

#35

Post by danShumway »

This 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-part...

[1]: https://developer.chrome.com/docs/privacy-sandbox/floc/

[2]: https://developer.chrome.com/docs/privacy-sandbox/attributio...

Re: Implement window.{alert, prompt, confirm} removal from cross-origin iframes

#36

Post by _jal »

trangus_1985 wrote: post #13

This 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 INSA…

Yeah, I will never be asking "Google, May I" to make HTML work. Contrary to Mountain View opinion, the web is not their walled garden.

Although it might be time to bring back those stupid "Best viewed in" banners, because everything old is new again.

Re: Implement window.{alert, prompt, confirm} removal from cross-origin iframes

#37

Post by throwaway2048 »

akersten wrote: post #20
bawolff wrote: post #9

Earlier quoted context omitted.

Idk 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.

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…

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

Re: Implement window.{alert, prompt, confirm} removal from cross-origin iframes

#38

Post by [deleted] »

akersten wrote: post #20
bawolff wrote: post #9

Earlier quoted context omitted.

Idk 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.

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…

[deleted]

Re: Implement window.{alert, prompt, confirm} removal from cross-origin iframes

#39

Post by stefan_ »

jdmichal wrote: post #22
elktea wrote: post #7

What's a legit use for this?

Examples from TFA: * Web-based REPL or IDE environments, where the iframe is typically the primary user interaction space. * Paid third-party website embedded into an internal website. * Hosted JS content such as Kongregate games. * Frames wrapping older webapps as part of an evolutionary uplift plan.

Those are not "use cases". What is being blocked here is alert. It's like I need to put "that also calls alert" at the end of every example you put forward.

Re: Implement window.{alert, prompt, confirm} removal from cross-origin iframes

#40

Post by _jal »

asdfasgasdgasdg wrote: post #34
trangus_1985 wrote: post #13

This 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 INSA…

What's insane about the timeline? They started talking about this a year and a half ago, approved it winter this year, and had it out in beta in May. How much longer should they take? What's insane about the opt-out process? It seems very easy to me. I was able to generate an opt-out token in about three minutes for example.com. I'm a backend developer so I don't know too much about web servers, but I imagine it woul…

> which you have to abide by using google.com or any other Google web property

When did my web site become a Google property?

Post reply on HN