Hacker News new | ask | show | jobs
by userbinator 1775 days ago
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.

3 comments

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

> How often is it that you have a malicious iframe on your website being used to trick people though?

Definitely more often than whatever hacky edge case websites relies on this behavior.

Such as a gaming website that hosts arbitrary JS games written to fit within a particular size limit? Code sample web IDEs that are designed to teach people how to code quickly? An iframed rich text editor? An embedded reporting widget that wants to remind users to save their changes before they navigate away on the parent page? An enterprise application that's using the strangler pattern to wall off greyfield parts of their application and those parts were written in 2004?

These are not common-use-cases-for-average-websites-on-the-net, but for web _apps_ where third-party `iframe` is the quickest way to real isolation between divergent code, iframes are pretty common. And `alert`, `confirm`, and `prompt` are not common in such code either, but when they are used they're often used in code paths that expect blocking behavior and are therefore definitely not amenable to alterations.

And the fact of the matter is that as the developer of a web application _I can still get this blocking behavior_. "All you need to do is have the parent and the child cooperate by sharing a TypedArray between the origins and use `Atomics.wait`" [1]. If by having the parent and the child cooperate I can get the blocking behavior, why not allow me to do it simply with a `sandbox` attribute, rather than having me publish a `@backcompat/alert` NPM module that both sides can pull in to polyfill a functioning `window.alert`?

[1]: https://twitter.com/KekitoF/status/1420220292429926400

The only time I've seen alert boxes used is in XSS demos and attack ads that break the sandbox to spawn 1000 popups that they say the FBI is blackmailing me, and that I should send 0.5 bitcoin to this address now.
> How often is it that you have a malicious iframe on your website being used to trick people though?

This is one of the most common phishing vectors.

When chrome was new and fresh... they fixed the alert dialog... making it possible to escape the tab that popped the alert and even close it... this was real progress. Kind of see their point with iframe but feel it was rash to assume you can just disable a feature. Everything should be permission dialogs... IMO... So then you open a new web app from Fancy CRM or productivity tool and you get a dozen permission dialogs for that domain... fine... do it once and move on... instead you login to Fancy CRM or productivity tool and it's broken now...
plenty of ads are malicious, and if you want to use an adbroker its super hard to control or address
> its super rare for it to be used legitly outside of debugging

Simply false. This change broke several of my companies apps, and it broke Salesforce, and God knows what else. And it's not just a layout problem; it's material behavior which changed.

> it broke Salesforce

take 1: Salesforce is already a broken heap of fertilizer

take 2: Hmm, didn't Google try and fail to acquire Salesforce?

It's not paranoid conspiracy theory, it's good ol' "fire and motion" - https://www.joelonsoftware.com/2002/01/06/fire-and-motion/. Google is absolutely doing this with the web. Everyone else is too busy either trying to catch up with Chrome or react to unending stream of Google's proposed changes to web standards - which keeps them pinned down, and gives Google the freedom of movement, allowing them to direct the evolution of the web as a platform.
That's the not the real complaint. The real issue is this: Opting out requires signing up with Google and become a customer of theirs: https://developer.chrome.com/origintrials/#/register_trial/2...
Who uses alert for debugging anymore?
And I don't know why you have to smear beliefs that differ from yours and the people holding them as "paranoid conspiracy." You can present your case without name calling (if you have one).
In fairness, the constant change is because other organizations have the brute force to keep up. If everyone else gave up on a browser they would stop changing things.
The entire web does this, not just Google.

Alert is pure garbage and should not have made it past the 90s. Also, basic auth popups need to go too. Not sure why browsers would ever make those focus stealing in the first place. There should not be one single way for a web application to steal focus. The current workaround is to download a buggy ad blocker (last time I used chrome, just like firefox it has no way to turn popups off).

Edit: I just remembered alert no longer steals focus on modern browsers (IIRC). But basic auth still does (at least on my 50 year old fork of firefox).

I would like to point out that stealing focus is part of the browser implementation. I don't think anyone would object to less stuff (if anything) stealing focus.

If the problem is "this functionality steals focus", how about making it not steal focus rather than removing it entirely on short notice? Why don't the Chrome developers focus on fixing their browser?

Ugly and limiting as they may be, I find standard UI widgets quite easy to leverage as a dev and as a user.

Though they may need to move beyond the line of death to mitigate spoofing.

basic auth is super useful for protecting staging sites, however.
>(at least on my 50 year old fork of firefox).

Since you're obviously from the future, can you give me tips on some stocks or sporting events to "invest"?

That's a way of saying "decades old".

Not to count years literally.

yes, and it's also understood that people are not really from the future with the information that I requested. Did you really think that was what I believed so that you needed to pedantically explain it to me?
Thought you meant he was wrong to claim "for 50 years".