Causing a lot of applications to break for a while was probably the only way the gain significantly meaningful attention. Who reads the docs? And if they they read the docs, who pays attention to deprecation warnings? Might as well be sounding off about climate change. On this one, Google gets a pass.
Google hits undo on Chrome browser alert change that broke websites, web apps
Google has temporarily reversed Chrome's removal of browser alert windows and other prompts created via cross-origin iframes after a rocky rollout over the past two weeks broke web apps and alarmed developers. An iframe, or Inline Frame, is a portion of a web page embedded in another web page. When it includes resources from a …
COMMENTS
-
-
Thursday 5th August 2021 08:45 GMT Anonymous Coward
If they'd attempted to notify people and been ignored this would be much less of an issue.
I like how you made sure to get the first post and make it pro-Google, that looks really natural. On this website we tend to favour the big players and not take the piss.
Yes, I am being sarcastic.
-
Friday 6th August 2021 11:32 GMT Cliffwilliams44
Well, Chromium announced last year that this would be depreciated! That means that this is coming to the upstream browsers! This is the problem we have with much of the "corporate" applications out there. The Devs use shoddy practices and seldom update their code! Like Our companies EPR only working in Internet Explorer until 2 years ago, like this same EPR not supporting LDAPS yet, when Microsoft has been trying to depreciate that for 2 years!
-
-
-
Thursday 5th August 2021 09:10 GMT Mike 137
"Tightening security always breaks stuff"
Sometimes it even breaks security. Recently, without any warning Firefox disabled a perfectly safe security plugin that had provided control over cross-domain content because it was considered to be "not signed". It worked though (for ages), but now it no longer protects me.
As a security professional I do so wish these externally provided "security" measures were optional, not forced on us without the choice.
-
-
Thursday 5th August 2021 08:30 GMT Pascal Monett
"Chrome has disabled its deprecation until August 15"
2022 ?
No, seriously, just ten more days ? How generous, Google.
It's obvious you are not the one putting in the overtime your changes have imposed.
Now that you've caused the stink, you could at least give something like 60 days for developers to analyze, define and implement the required changes.
It's not like the Web will break in that time anyway.
-
Thursday 5th August 2021 09:56 GMT Anonymous Coward
Re: "Chrome has disabled its deprecation until August 15"
But ten days is enough for Google to throw untested code into Chrome and force it on the masses. They are just passing on their Best Practices to other companies to follow their lead in throwing out untested code.
Next those companies need to also learn how to ignore their clients screams when things fail to work.
-
-
Thursday 5th August 2021 08:33 GMT Sgt_Oddball
So what of...
Card payment services? Alot of them use an embedded iFrame to offload liability within the PCI-DSS compliance framework. Think of a large company with many different brands taking payments, do you a) Certify each and every site to the top PCI-DSS level 1 merchant compliance with all the security checks that entails, b) Create a separate entity to handle all payments for all sites and use an iFrame to handle the payment (thus meaning no money is put through each individual site but only the payment service, and only needs one site to be fully scrutinised). Or c) Hand it over to a 3rd party provider like PayPal for example... again via an iFrame.
-
Thursday 5th August 2021 10:02 GMT Tom 38
Re: So what of...
There's no problem with embedded iframes, just with an iframe using alert, prompt and confirm as though they are the main website.
Don't do those things, and you're golden. HSBC don't, Paypal don't.
The way Google rolled it out is bad, but using alert/prompt/confirm is bad UI in 2021 anyway. This change isn't going to break things significantly , because the vast majority of iframe users don't use these modal prompts anyway, and will force the ones that do to correct their bad UI, whilst preventing bad actors from abusing it.
What they should have done, instead of forbidding it and instantly breaking these apps with bad UI, is present the message in a way that is ugly and would make users complain, whilst still allowing the app to work.
Eg, before displaying the alert, chrome could have displayed a message "This app is attempting to display an alert which does not come from the original website" and force the user to click OK before displaying the actual message. This would have not broken the apps that are still using it, but they would want to fix their app so that users no longer see such a message.
-
-
-
Friday 6th August 2021 11:39 GMT Cliffwilliams44
Re: The browser is the new operating system
"Don't forget to test your app on:
* previous versions of Google Chrome (for those orgs who fix on a particular version)
* Firefox
* Microsoft Edge
* Internet Explorer 6"
Really? This is a fight we've had to have with both internal and external developers over and over.
"It only works on Chrome X.X.X" No! that version has security vulnerabilities! We will not allow it!
"You must use out app in I.E!" Hell no!
-
-
This post has been deleted by its author
-
Friday 6th August 2021 11:41 GMT Cliffwilliams44
Re: Other browsers are available
How many of these other browsers are Chromium based! This is not just a Google issue, it is ALL chromium based browsers! And if some other browser i.e. Firefox, allows bad practices that create security holes should we allow that in our organization? I think not!
-
-
Thursday 5th August 2021 14:19 GMT Anonymous Coward
alerty
This is a huge problem especially with mobile web browsers.
Malicious ads popping alerts claiming the users device is infected with viruses etc,
I've been tracking malicious mobile ads using AdMaven, Taboola and ADFly for several months.
One of the scripts used is Alerty:
https://github.com/undead25/alerty
-
Thursday 5th August 2021 22:19 GMT Someone Else
With this change I am scrambling to implement an ugly
window.parent.postMessage
workaround because chunks of our web app are now broken for our tens of thousands of users."Well, perhaps cross-origin iframes were not such a good idea (read: convenient hack) in the first place?
Reminds me of the hue and cry that accompanied the removal of the ALTER verb from Cobol-80. (For those of you are not Boomers, Cobol's ALTER verb allowed one to write self-modifying code; a practice that ranks right up there with the indiscriminate use of GOTO1 in the level of disdain.)
1Well, for languages that are block structured, anyway. Not much you can do in Fortran IV without it, to be sure, but for C...
-
Friday 6th August 2021 20:42 GMT Michael Wojcik
Not 1980. ALTER was moved to "Obsolete" status in COBOL-85 and removed entirely in COBOL-2002.
It might be worth noting that ALTER didn't enable arbitrary code modifications. It only permits changing a specific subset of GO TO statements (they have to be non-computed GO TOs that are the only statements in their enclosing paragraphs) to refer to different labels.
Since COBOL's GO TO uses paragraph names as its labels, and given the restrictions on COBOL's paragraph-level control flow and the aspects of it which the standard leaves to the implementation, ALTER can easily be implemented without actually modifying code at runtime. It can be treated as syntactic sugar for conditional branches or implemented with (the equivalent of) function pointers, for example.
The primary argument against ALTER was that it made control-flow analysis too difficult, but it's really not any worse than function pointers in C. In fact it's better, because the target has to be in the same translation unit and has to be a literal; you can't play games with, say, dynamic symbol resolution as you can in many C implementations (if not in strictly-conforming C). Hysteria over an inflated bugbear.
-
-
Friday 6th August 2021 11:46 GMT Cliffwilliams44
Re: Well...
Yeah, it it. I would not say this was a "move fast" event. I have not looked but I'll wager this was somewhere on Googles developer sites stating this change was eminent. It certainly was announced by the upstream Chromium team.
If one of our vendors apps was broken by this, yeah we would roll back a version if we had to but we certainly would put serious pressure on them to fix it if they want to remain a vendor for us.
-
-
Friday 6th August 2021 15:13 GMT JBowler
Disabling JavaScript should work too
It should work because unlike the main window the IFRAME does not cause any notice of "JavaScript disabled" and there is no way for most people to work out how to re-enable JavaScript for the IFRAME domain because it is impossible to discover the domain without UTSL (and maybe not even then).
I have JavaScript disabled in the sync'ed Chrome settings; so the disability applies to all machines running chrome which sync user settings. E.g. I set it up on Chrome on Windows 10 and it auto-applies to Chrome on Linux. Then users enable JavaScript for web sites where something doesn't work but they can't enable it for ad sites and other IFRAME nonsense because they simply don't know it is there. So far as I know enabling it for the advertised domain does not enable if for random frames from spy/ad/phish/secret domains embedded within the content. (Someone tell me if it does :-)
I also seem to have 92.0.4515.107 Chrome installed with no problems but a user machine that was rebooted yesterday is now at 4515.131 Chrome support does at least say how to de-upgrade and prevent automatic upgrades - considerably better than iOS.
I also installed pi-hole recently. Absolutely not one single complaint! In fact I think everything is going faster, but then I live in the land of no internet (the rural US).