11–20 of 160 posts
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…
What's a legit use for this?
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
What's a legit use for this?
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 :
> _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_
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.
What's a legit use for this?
Penetration 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.
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…
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…
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".
What's a legit use for this?
Penetration 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.
Earlier quoted context omitted.
Who 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.
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.
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.