I don't think this is a duplicate. This story is reporting on how Chromium is (at least, temporarily) restoring support for alert/prompt/confirm from cross-origin iframes.
This is what you get, when google has monopoly on the web platform. They will drop support for standards, because they want to and they can. And we won’t have any say in their decisions.
I mean, the gall they have to shove their burden onto us, the developers. Google is a trillion dollar company. If they think, that alerts are confusing, they have all the money in the world to make them not confusing.
But, I guess, dropping support is what google usually does.
alert was never a W3C standard. It was a non-standard browser feature that happened to be widely implemented in the early days of the web. It was never part of any planned/agreed addition of well-thought-out features to the web.
The only time it has been "standardized" is when the WHATWG recently decided it would be a good idea to describe the behaviour of all the legacy non-standard browser APIs that have been lying around in browser implementations since the early days of Javascript's existence. The WHATWG have strictly described this behaviour for alert within the "User Prompts" section of the HTML specification: a new section to describe an ancient function.
If it were only a defacto standard I'd say they'd be even more justified in deprecation.
It is now an actual standard though; I was just pointing out the history and reasoning behind its addition to the current standard.
Given its WHATWG policy to define and codify the behaviour of every feature ever added broadly, if we believe no standard should ever be deprecated we'll never be able to deprecate anything at all and be stuck with every bad decision ever made.
> alert was never a W3C standard. It was a non-standard browser feature that happened to be widely implemented in the early days of the web. It was never part of any planned/agreed addition of well-thought-out features to the web.
That's the case for flatten too, it was just a widely used library, but the point is not to respect the standards but to not break the web.
Oh how times change. It's not so long since this infamous sentiment (as espoused by one much more infamous browser vendor) was widely seen as the regressive excuse it is.
A technology that is not iterative is representative of a community that cannot learn.
You implied that when you responded to your parent comment quoting their remark about following standards, and you said alert is not a W3C standard but it's just described by WHATWG.
If you want to interpret your own comments in another self-consistent way, please elaborate.
> This is what you get, when google has monopoly on the web platform.
This isn't even an obviously bad idea. It is bad for web developers, but I don't think it is easy to argue that web developers are the most important demographic for Google to cater to. If this is the sort of terror that monopolies are meant to be inflicting then the concept is barely important enough to get a mention.
I don't like Google, and I remember the IE6 days. When Chrome is even a little comparable to what MS used to manage then maybe people should start complaining. This is nothing.
We might not work for Google, but we know a thing or two about web development and its surrounding ecosystem.
Pushing the implementation details for a replacement down onto web developers is terrible idea from an accessibility standpoint: It makes it highly likely that hand-rolled, inaccessible implementations will become common.
The Right Way to effect this change is to spec out and implement an alternative API.
Google thought Google+ was a very good idea. Didn’t mean that it was a good idea.
Removing features from web platform is, at least for me, a very bad move. If only because that it will spawn millions of half-baked replacement libraries with a whole lot of other security problems.
Yeah, you disagree with Google. They might be wrong and you might be right. That isn't important though. You need to make an argument about why you are right and why they are wrong.
If your argument is you just don't like it, then Google has a multi-billion person user-base made up of people who trust Google's opinions on how to make a web browser more than literally anyone else.
Even if every HN reader doesn't like what Google is doing here, that still doesn't mean anything except that the tech community doesn't like it. The tech community sometimes doesn't like things that are, nevertheless, good decisions.
And, on the point at hand, I don't see why getting rid of an alert box is a bad idea. They are kind of annoying. I don't think removing them is a reasonable example of monopolistic excess.
> If only because that it will spawn millions of half-baked replacement libraries with a whole lot of other security problems.
If alerts and confirms are kinda annoying, wait till you will have the same thing, but custom-built for every site. Oh, and you will not be able to “block further alerts from this site”, as you can now.
Google is always right. Please download Google Chrome to see this site. You have an add blocker. Please disable it to see content (and let Google analyse you). Good luck living in a world without Google.
This isn't about support, it is a sane security decision. Imagine finding that a door to your large shared office space is missing and people were coming in and stealing things. So you install a new door and suddenly people start saying... How dare you put a door there that people were using to steal things. The gall you must have to shove this burden onto us.
They make it very easy for a page to present information to the user in a way that looks like it's coming from their system rather than something under the page's control?
Consider that both Chrome and Firefox have already changed the UI to do things like make the dialog title indicate that this is content from a web page or, in Firefox's case, add an option to prevent a page from spewing repeated alerts. Why should the answer be to break correctly-functioning applications around the web rather than just continuing that process of making these dialogs distinct from the platform controls? There's no standard requiring that they be implemented as a Windows MessageBox() call.
Consider what it'd look like as a polyfill which just slams a <dialog> block with inline styles (position:absolute, etc.) into the page — there's no reason why Chrome couldn't implement something better than that and doing so would avoid breaking 3 decades of currently running code chasing after a very minimal security improvement.
I say minimal because while it's possible for an attacker now to use confirm() to install a Windows update, removing that function does not mean they'll give up and stop trying. It means that they will add a fraction of a percent to their existing development time making some JavaScript which pops up a dialog styled to look like the platform defaults for the OS your browser advertises. We know that because attackers already spend considerable amounts of time trying to look like legitimate sites and this is not going to be a prohibitive amount of additional work unless there's a sharp decline in the amount of money at play with ransomware and espionage.
not to mention not letting people enable them again in their iframes like other security features (although i guess this is somewhat of a moot point since they plan to get rid of them completely)
Perhaps a controversial take, but I would be happy to see alerts removed altogether. I'm sure someone can point to a few legitimate uses of them, but in the grand scheme of things, they're usually terrible for user experience, as they block everything else (which is the point). This is also often used as a way to scam less computer literate people with "microsort security" alerts, that keep getting reopened when closed.
I get that there are lots of JS tutorials out there that use it as a way to show simple interactions, but that's a very weak argument for keeping an API that is potentially harmful.
You're underestimating the level of breakage here, it's not just a few tutorial sites it's tens of millions of websites, many unmaintained. Like them or not alert(), confirm() and prompt() are key pieces of functionality depended on for literally decades now. I'm trying to imagine the economic cost of this change and it's just enormous.
I understand that. But that was the case with popups as well. Remember when we needed popup blockers? Straight up removing the functionality is of course a drastic measure, so realistically I could see something like what we did with popups, where the browser first asks you if you'd like to allow alerts on the page, and only allow them to be shown if the user explicitly chooses so.
it's not like you couldn't do the exact same microsort security alerts with a position:absolute overlay. Google can just make the alert window explicitly stay within the viewport instead of breaking the internet.
I do not see any added value for alerts. They only interfere with normal work. "Site wants to send you alerts". No thanks. They have most of the issues behind a paywall so they just want to serve more ads. If I need something, i will look for it. The newspaper sites are the worst offenders. No i do not need propaganda alerts.
Google has an engineering culture that is biased towards chasing the next big thing. If you're not building something new and noteworthy then it's not valuable. This is good for Google as a business, but can hurt consumers by leaving them with dead and dying products. On the other hand, the web is powerful because it is ubiquitous, stable, and democratised.
So you take Google engineers, coach them and reward them for demonstrating impact through building new features. Change is good, stability is bad. Then you put them in charge of the web platform. The natural result is an avalanche of new standards and an inclination to discount the status quo.
As a tangible example, in response to this one Chrome engineer Tweeted "breaking changes happen often on the web, and as a developer it's good practice to test against early release channels of major browsers to learn about any compatibility issues upfront."
That strikes me as the wrong attitude when you're working on the web. Change should be a last resort, not an expected side effect of you achieving some other goal.
Also since web browsers are taking more and more of the operating systems responsabilities (providing API to buid applications) they should be more careful with compatibility of applications. Reversing the responsability is not acceptable.
Coincidentally I just got burned today by some of those Chrome changes: a web app I'm developping has its container exposed on port 10080 for some reason. Impossible to open it with Chrome, because it decided most ports are now "dangerous". Took me 10 minutes to figure out, as it was working fine before. As relaunching the thing involve some manual steps, I solve the problem using Safari... It is becoming more and more difficult to do things not vetted by Google, and that's scary.
This is definitely not the most important reason to keep `alert`, but I'd like to share it anyway:
My girlfriend recently decided that she wants to learn programming. Given that she already knows some HTML and CSS, I thought JavaScript was the best option as her very first language, as she could apply what she learns easily. So I decided to teach her programming with JS.
In these lessons I've been teaching her how to do basic input and output using `alert`, `prompt` and `confirm`. I know these are almost never used in professional projects, but for beginners these are very practical. They are easy to use and you can test everything in the browser without having to deal with all the overwhelming complexity of the usual JS toolchains. It's so sad that they are going away :( This definitely would make JS a bit less appealing for the complete beginner.
I had exactly the same thought, my wife is doing a Shecodes course and the confirm and alert features are very good simple UI components that require no additional work, it allows beginners to piece together a complete experience without having to build a whole UI stack.
And letting go of beginners... removing them seems like the reverse of what we need to do here. They should be improved to the point that no one needs custom confirm dialogs anymore.
It makes no sense at all that we require so much reinvention of the wheel on the web, even down to these ultra-generic features.
> I know these are almost never used in professional projects
Well, ignore me clearing my throat and wiping away the sweat on my head, but at least confirm() is quite useful.
Yes, I could make something that acutally looks nice and has better usability, but sometimes you want to ask a quick question and looks aren't important.
Still, I don't think these commands are affected, just when the script comes from another source, which is a new policy, since script origin wasn't ever questioned by browsers.
> Major browser vendors are generally aligned about wanting to move the platform away from alert() and friends, even though it will unfortunately involve some breakage.
That at least doesn’t seem like any kind of near-future thing.
I just hope there’ll be some replacement, we use confirm() to prevents users from losing changes that weren’t saved (just like many other sites including fastmail and google)
They're on another domain they own, but they are on another domain (cdpn.io) and the cross-origin concern does apply. They do that because they have auth cookies on codepen.io and don't want them exposed to the iframe.
What about console? It is easy to use for beginners and really powerful if you want to dig deeper. Even as a beginner I always found alert() really awkward. Now that I am programming Javascript for a living I never use it.
The chromium bug from the TFA [1] *only* has 76 comments, as of writing this. Seventy six. Out of millions of users. And of those 76, it's not all pro-revert rhetoric. Any outrage here caused by the upstream changes seems quite hyperbolic.
As a user, I'm annoyed my browser will now be subject to a flawed implementation for however much longer it now takes to revert the reversion (de-facto standard or not). I most certainly can't be alone in this stance. While I empathize a subset of developers may have been caught off guard by changes, my empathy has limits: their inconvenience is not worth my browser safety. Why must users suffer at the hand of a few chest-thumping devs?
A little deference for history I think would also go a long way here: time and again Google has to kick the industry hard in it's complacency [2][3]. How quickly the industry seems to have forgotten that not all that long ago, developers [and administrators] had to be dragged kicking and screaming like toddlers, to support HTTPS adoption (and corresponding changes to the chrome UI). Was that change difficult then? You bet. Was it a net-good change in the long run? Hell yes.
As Bruce Wayne said to Alfred after laying waste to League of Shadow's headquarters in Nolan's Batman Begins:
"People need dramatic examples to shake them out of apathy [...]"
Chrome Security team, if you're reading this, keep on trucking.
> Why must users suffer at the hand of a few chest-thumping devs?
The only suffering here is at the hands of the Chrome developers, who apparently feel entitled to break extremely widely used features that have worked perfectly fine for the past 20+ years.
This change broke Salesforce [1] among many others: that's literally millions of affected users. And I can promise you that not one of them cares about Chrome's internal implementation details.
Do you have any idea how much of the web will break if alert(), confirm() and prompt() are removed? Tens of millions of websites, many of which are no longer maintained will stop working. This is the destruction of the web over a UX issue - fix the UX issue, don't break the web!
Those functions should be deprecated and new applications should be discouraged from using them, but they should never be removed.
I am not getting paid for it unlike some people in Google that try to remove alert() and break stuff for everyone instead of fixing bad UI of their browser.
They're planning to get rid of first party alerts as well, it says so in the article. And in the meantime, there's no way to opt out of breaking cross-origin alerts, which is not great for things like codepen.
The security issues with alert is not about getting access to the OS, but having a third-party (cross-origin iframe) display a message to the user, when the user doesn't know that the message is not from the site they are visiting.
They also could very well improve the cross-origin alerts to say "This message is from ANOTHER website embedded in this tab, please act carefully. (source: xxx.com)" instead of outright removing it.
That is... a rather odd argument. As a user, why would I care if the main thread is blocked while a modal alert is displayed? If anything, that's probably the expected behaviour!
An argument I could understand would be that `alert` etc look like system prompts, rather than something from the browser - but that's a browser concern that Chrome, Firefox, Edge, Safari etc could easily solve if they wanted.
I mean, the gall they have to shove their burden onto us, the developers. Google is a trillion dollar company. If they think, that alerts are confusing, they have all the money in the world to make them not confusing.
But, I guess, dropping support is what google usually does.
alert was never a W3C standard. It was a non-standard browser feature that happened to be widely implemented in the early days of the web. It was never part of any planned/agreed addition of well-thought-out features to the web.
The only time it has been "standardized" is when the WHATWG recently decided it would be a good idea to describe the behaviour of all the legacy non-standard browser APIs that have been lying around in browser implementations since the early days of Javascript's existence. The WHATWG have strictly described this behaviour for alert within the "User Prompts" section of the HTML specification: a new section to describe an ancient function.
It is now an actual standard though; I was just pointing out the history and reasoning behind its addition to the current standard.
Given its WHATWG policy to define and codify the behaviour of every feature ever added broadly, if we believe no standard should ever be deprecated we'll never be able to deprecate anything at all and be stuck with every bad decision ever made.
That's the case for flatten too, it was just a widely used library, but the point is not to respect the standards but to not break the web.
Oh how times change. It's not so long since this infamous sentiment (as espoused by one much more infamous browser vendor) was widely seen as the regressive excuse it is.
A technology that is not iterative is representative of a community that cannot learn.
Neither was Javascript.
There are many other web specs that are still only done at W3C, the only ones to move to WHATWG are the ones listed here: https://spec.whatwg.org/
If you want to interpret your own comments in another self-consistent way, please elaborate.
This isn't even an obviously bad idea. It is bad for web developers, but I don't think it is easy to argue that web developers are the most important demographic for Google to cater to. If this is the sort of terror that monopolies are meant to be inflicting then the concept is barely important enough to get a mention.
I don't like Google, and I remember the IE6 days. When Chrome is even a little comparable to what MS used to manage then maybe people should start complaining. This is nothing.
Google thinks this is a good idea, and Google knows a lot more about the Chrome userbase than you do.
Pushing the implementation details for a replacement down onto web developers is terrible idea from an accessibility standpoint: It makes it highly likely that hand-rolled, inaccessible implementations will become common.
The Right Way to effect this change is to spec out and implement an alternative API.
Removing features from web platform is, at least for me, a very bad move. If only because that it will spawn millions of half-baked replacement libraries with a whole lot of other security problems.
If your argument is you just don't like it, then Google has a multi-billion person user-base made up of people who trust Google's opinions on how to make a web browser more than literally anyone else.
Even if every HN reader doesn't like what Google is doing here, that still doesn't mean anything except that the tech community doesn't like it. The tech community sometimes doesn't like things that are, nevertheless, good decisions.
And, on the point at hand, I don't see why getting rid of an alert box is a bad idea. They are kind of annoying. I don't think removing them is a reasonable example of monopolistic excess.
If alerts and confirms are kinda annoying, wait till you will have the same thing, but custom-built for every site. Oh, and you will not be able to “block further alerts from this site”, as you can now.
They are planning to drop support for alert, confirm and prompt. Not in iframes, but everywhere. How are they a security problem?
Having clear, simple ways to do things like alert(), confirm() and prompt() is incredibly valuable for doing simpler/quicker stuff on the web.
Pegasus wasn't even a browser bug, it was installed via text message IIRC.
Consider what it'd look like as a polyfill which just slams a <dialog> block with inline styles (position:absolute, etc.) into the page — there's no reason why Chrome couldn't implement something better than that and doing so would avoid breaking 3 decades of currently running code chasing after a very minimal security improvement.
I say minimal because while it's possible for an attacker now to use confirm() to install a Windows update, removing that function does not mean they'll give up and stop trying. It means that they will add a fraction of a percent to their existing development time making some JavaScript which pops up a dialog styled to look like the platform defaults for the OS your browser advertises. We know that because attackers already spend considerable amounts of time trying to look like legitimate sites and this is not going to be a prohibitive amount of additional work unless there's a sharp decline in the amount of money at play with ransomware and espionage.
Can you cite this? Or is this just wild speculation?
Also this: https://twitter.com/Rich_Harris/status/1422930436850860033
I get that there are lots of JS tutorials out there that use it as a way to show simple interactions, but that's a very weak argument for keeping an API that is potentially harmful.
There may be millions of sites using these functions legitimately, but not inside an iframe.
So you take Google engineers, coach them and reward them for demonstrating impact through building new features. Change is good, stability is bad. Then you put them in charge of the web platform. The natural result is an avalanche of new standards and an inclination to discount the status quo.
That strikes me as the wrong attitude when you're working on the web. Change should be a last resort, not an expected side effect of you achieving some other goal.
Coincidentally I just got burned today by some of those Chrome changes: a web app I'm developping has its container exposed on port 10080 for some reason. Impossible to open it with Chrome, because it decided most ports are now "dangerous". Took me 10 minutes to figure out, as it was working fine before. As relaunching the thing involve some manual steps, I solve the problem using Safari... It is becoming more and more difficult to do things not vetted by Google, and that's scary.
My girlfriend recently decided that she wants to learn programming. Given that she already knows some HTML and CSS, I thought JavaScript was the best option as her very first language, as she could apply what she learns easily. So I decided to teach her programming with JS.
In these lessons I've been teaching her how to do basic input and output using `alert`, `prompt` and `confirm`. I know these are almost never used in professional projects, but for beginners these are very practical. They are easy to use and you can test everything in the browser without having to deal with all the overwhelming complexity of the usual JS toolchains. It's so sad that they are going away :( This definitely would make JS a bit less appealing for the complete beginner.
And letting go of beginners... removing them seems like the reverse of what we need to do here. They should be improved to the point that no one needs custom confirm dialogs anymore.
It makes no sense at all that we require so much reinvention of the wheel on the web, even down to these ultra-generic features.
Well, ignore me clearing my throat and wiping away the sweat on my head, but at least confirm() is quite useful.
Yes, I could make something that acutally looks nice and has better usability, but sometimes you want to ask a quick question and looks aren't important.
Still, I don't think these commands are affected, just when the script comes from another source, which is a new policy, since script origin wasn't ever questioned by browsers.
> Major browser vendors are generally aligned about wanting to move the platform away from alert() and friends, even though it will unfortunately involve some breakage.
- https://twitter.com/estark37/status/1422694855390629893
That at least doesn’t seem like any kind of near-future thing.
I just hope there’ll be some replacement, we use confirm() to prevents users from losing changes that weren’t saved (just like many other sites including fastmail and google)
See these tweets by their cofounder: https://twitter.com/chriscoyier/status/1422940724295786503?s... and https://twitter.com/chriscoyier/status/1420033471376920578?s...
As a user, I'm annoyed my browser will now be subject to a flawed implementation for however much longer it now takes to revert the reversion (de-facto standard or not). I most certainly can't be alone in this stance. While I empathize a subset of developers may have been caught off guard by changes, my empathy has limits: their inconvenience is not worth my browser safety. Why must users suffer at the hand of a few chest-thumping devs?
A little deference for history I think would also go a long way here: time and again Google has to kick the industry hard in it's complacency [2][3]. How quickly the industry seems to have forgotten that not all that long ago, developers [and administrators] had to be dragged kicking and screaming like toddlers, to support HTTPS adoption (and corresponding changes to the chrome UI). Was that change difficult then? You bet. Was it a net-good change in the long run? Hell yes.
As Bruce Wayne said to Alfred after laying waste to League of Shadow's headquarters in Nolan's Batman Begins:
"People need dramatic examples to shake them out of apathy [...]"
Chrome Security team, if you're reading this, keep on trucking.
- [1] https://bugs.chromium.org/p/chromium/issues/detail?id=106508...
- [2] https://bugs.chromium.org/p/chromium/issues/detail?id=106508...
- [3] https://security.googleblog.com/2018/02/a-secure-web-is-here...
The only suffering here is at the hands of the Chrome developers, who apparently feel entitled to break extremely widely used features that have worked perfectly fine for the past 20+ years.
This change broke Salesforce [1] among many others: that's literally millions of affected users. And I can promise you that not one of them cares about Chrome's internal implementation details.
[1] https://help.salesforce.com/articleView?id=000362676&languag...
Those functions should be deprecated and new applications should be discouraged from using them, but they should never be removed.
How many of those who know, have reported or commented on bugs which have never been fixed?
I just commented in https://github.com/whatwg/html/issues/6897#issuecomment-8933... and https://github.com/whatwg/html/issues/2894#issuecomment-8933... - and even that is too much given that I am using my unpaid hobby time for it.
I am not getting paid for it unlike some people in Google that try to remove alert() and break stuff for everyone instead of fixing bad UI of their browser.
Can we not put somekind of VM environment around the entire browser, so that it's not an entry door to someone's OS ?
An argument I could understand would be that `alert` etc look like system prompts, rather than something from the browser - but that's a browser concern that Chrome, Firefox, Edge, Safari etc could easily solve if they wanted.