Google hits undo on limiting JavaScript capabilities in cross-origin iframes(theregister.com)
theregister.com
Google hits undo on limiting JavaScript capabilities in cross-origin iframes
https://www.theregister.com/2021/08/05/google_chrome_iframe/
86 comments
Duplicate: https://news.ycombinator.com/item?id=28055160
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.
The story itself even points back to that!
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.
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.
> drop support for standards
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.
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 being part of every browser makes it a defacto standard.
Are you equally mad about moves to eliminate cross-origin cookies? That was part of every browser.
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.
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.
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.
> 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.
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.
> alert was never a W3C standard.
Neither was Javascript.
Neither was Javascript.
W3C doesn't matter much, WHATWG is the spec we follow, W3C just chases after them. So don't equate "standards" with "W3C standards".
For some specs, yes, for others no. For example, WHATWG does not do the ECMAScript spec (that's https://tc39.es/), or CSS (that is W3C).
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/
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/
not sure where I equated standards with W3C standards.
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.
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.
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.
What? Why should we tolerate bad behavior? Only because it’s less bad than Microsoft’s? That is not a very high bar, you know.
We shouldn't tolerate bad behaviour. But you'll have to make an argument that it is bad behaviour.
Google thinks this is a good idea, and Google knows a lot more about the Chrome userbase than you do.
Google thinks this is a good idea, and Google knows a lot more about the Chrome userbase than you do.
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.
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.
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 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.
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.
I think it's worth noting that the proposed change is only to prevent alerts from cross origin iframes, not in general.
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.
When did IE6 break existing websites? If anything, Microsoft's problem was the reverse -- never wanting to break anything, which lead to stagnation.
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.
Here’s the thing. It is not our problem that google doesn't want to make alerts less confusing.
They are planning to drop support for alert, confirm and prompt. Not in iframes, but everywhere. How are they a security problem?
They are planning to drop support for alert, confirm and prompt. Not in iframes, but everywhere. How are they a security problem?
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?
That's very much a browser interface design problem, not a problem of the feature itself.
Having clear, simple ways to do things like alert(), confirm() and prompt() is incredibly valuable for doing simpler/quicker stuff on the web.
Having clear, simple ways to do things like alert(), confirm() and prompt() is incredibly valuable for doing simpler/quicker stuff on the web.
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.
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.
Then just make the box look more like part of the webpage. They could even put a nasty warning message in the box, as they completely control it.
This is about CSRF. Ever heard the phrase blinded by hate or blind hatred?
How are alert and CSRF related at all?
Because this is specifically in regarding to calling them from an iframe.
> They are planning to drop support for alert, confirm and prompt. Not in iframes, but everywhere.
Can you cite this? Or is this just wild speculation?
Can you cite this? Or is this just wild speculation?
The Register cites this: https://github.com/whatwg/html/issues/6897#issuecomment-8857...
Also this: https://twitter.com/Rich_Harris/status/1422930436850860033
Also this: https://twitter.com/Rich_Harris/status/1422930436850860033
Thank you!
[deleted]
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.
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.
This is the fix. Deprecate alerts gracefully in favor of the native dialogue element!
I still see them everywhere.
It's only blocking when inside an iframe.
There may be millions of sites using these functions legitimately, but not inside an iframe.
There may be millions of sites using these functions legitimately, but not inside an iframe.
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.
I think you're thinking of push notifications
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.
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.
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.
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.
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.
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.
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.
No, this is about alerts from cross origin content, like from an iframe that loads from a different origin than the parent page
Google is planning to remove alerts entirely: https://twitter.com/Rich_Harris/status/1422930436850860033
Direct source:
> 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)
> 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)
It would still break sites like codepen.io that use iframes for this.
codepen's iframes are their own, not cross-origin
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.
See these tweets by their cofounder: https://twitter.com/chriscoyier/status/1422940724295786503?s... and https://twitter.com/chriscoyier/status/1420033471376920578?s...
See these tweets by their cofounder: https://twitter.com/chriscoyier/status/1422940724295786503?s... and https://twitter.com/chriscoyier/status/1420033471376920578?s...
if they were on the same domain you could load iframes with the parent site and do arbitrary CSRF
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.
- [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...
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...
> 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.
[1] https://help.salesforce.com/articleView?id=000362676&languag...
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...
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.
Those functions should be deprecated and new applications should be discouraged from using them, but they should never be removed.
How many of those millions of users know where to report a bug?
How many of those who know, have reported or commented on bugs which have never been fixed?
How many of those who know, have reported or commented on bugs which have never been fixed?
The HTTPS adoption switch worked only because Let's Encrypt happened. Otherwise people would have screamed blue murder.
> has 76 comments, as of writing this. Seventy six. Out of millions of users.
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.
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.
Yes, please, make my browsing more secure by removing first party alerts. So much security will be achieved /s
It's explicitly cross-origin.
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.
At some point we'll need to weigh security vs usability... I'm getting tired of seeing my browser becoming less and less open.
Can we not put somekind of VM environment around the entire browser, so that it's not an entry door to someone's OS ?
Can we not put somekind of VM environment around the entire browser, so that it's not an entry door to someone's OS ?
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 say they want to get rid of first party alert as well though, and don't offer any sort of opt-out for trusted iframes
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.
When they say they need to remove alert completely because it blocks the main thread you can see how disconnected from reality they are.
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.
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.
This is indeed a very strange argument against alerts.