Hacker News new | ask | show | jobs
by trangus_1985 1786 days ago
This makes a lot of sense, and is (IMO) a really great thing to do for users. IMO Cross Origin iframe alert/prompt should only be allowable with CSP rules explicitly permitting the cross origin iframe in the first place (in allowlist capacity). The amount of abuse this has seen and will see is a blight, especially on the average user.

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

4 comments

Switch to Mozilla? They are positive to this, and Webkit also. That is often the case, Chromium just has a faster turn-around then the others so usually are first to implement.

The discussion about this started a year ago with the individual browsers and WHATWG.

https://bugzilla.mozilla.org/show_bug.cgi?id=1624978

From the Google discussion on this change back in March, located here [1].....

> "We haven’t engaged with other browser vendors regarding this change yet, but plan to submit a spec change proposal once the change is approved for Chrome. Since PRs to the HTML spec require one more vendor to support (and none to oppose), we’ll reach out to other vendors before sending the PR."

The first comment response reads.....

> "Although the spirit is right, this isn't quite the correct approach procedurally. It's best to submit a specification pull request before any Intents are approved, to better help promote cross-vendor discussion, and allow the API owners to assess interop risk by looking at the spec (and accompanying web platform tests). The specification pull request doesn't have to be approved, but it should exist, so that there is a public record of what we are implementing at the level of detail of a full specification."

The next comment agrees.....

> "I'd like to second that. A part of the reason we have our launch process is to evaluate interop risk, which requires engaging with other vendors to see if they'd follow our path. A spec PR would enable them (as well as the API owners) to evaluate what this change actually means and allow them to express their opinions on it. FWIW, I'd be surprised if they weren't supportive of this, assuming we prove that this change is web compatible."

So here we see on full display Google acknowledge that they have enough market share to ignore other vendors, awknoledge that it is not in the web's best interest to do so, and yet somehow that part of the discussion was allowed to completely die out.

So yeah, switch to Mozilla. The conversation they had on the topic was much more aligned with what I want to see from my supply chain than the conversation I saw over at Google.

[1] https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXi...

> awknoledge that it is not in the web's best interest to do so

The two people you are quoting don't appear to be Google employees. Maybe I'm wrong, but it appears that the Google employees are usually using @chromium.org or @google.com email addresses.

Edit, correction: at least one of the people is a Google employee using a personal email address. I regret the error. Nonetheless, I don't agree with the characterization of the responses.

Not a suitable answer for website owners. Even if they literally asked all their customers to switch, end users won't.
The issue isn't the cross origin alert change. It's the TOS required and opt-out process.
Microsoft Edge released 92.0.902.62 today which now re-allows the dialogs in cross domain iFrames. We are suggesting that our user base moves from Chrome to Edge.
Even MS couldn't catch this regression? I wish MS could.
Yeah, I will never be asking "Google, May I" to make HTML work. Contrary to Mountain View opinion, the web is not their walled garden.

Although it might be time to bring back those stupid "Best viewed in" banners, because everything old is new again.

They never left the B2B and corporate world.
What's insane about the timeline? They started talking about this a year and a half ago, approved it winter this year, and had it out in beta in May. How much longer should they take?

What's insane about the opt-out process? It seems very easy to me. I was able to generate an opt-out token in about three minutes for example.com. I'm a backend developer so I don't know too much about web servers, but I imagine it would take another ten minutes for an experienced person to make a commit that adds the reverse origin trial header to the default headers for their servers, possibly as a cherry pick to their existing release.

What's weird about the TOS? It's just the Google standard TOS, which you have to abide by using google.com or any other Google web property. 99.99% of possible interested developers are already covered by it, right? There is no way Google could offer you a service like this, or even documentation for it, without some kind of terms of service.

R.e. switching to Firefox, sure, browser diversity is great, but that won't affect anyone who uses your web site. They'll still be on Chrome or Safari, so this type of thing is still going to be something you have to handle. And anyway I guess that Mozilla will probably remove this option before too long as well.

“But look, you found the notice, didn’t you?”

“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”

This is the noticeboard for upcoming proposed changes for Blink. You may not have known about its location before, but that does not mean it was hidden away or intentionally obscure.
And now everyone who has ever made a website needs to carefully track that location, just because it might otherwise quietly break their production site? There are plenty of better ways for people to spend their time than searching through every website of everything you have ever made code for.
Software changes. It's an unfortunate reality of the profession. If you're someone who relies on the web platform for your living, you, at a minimum, need testing on the beta and dev versions of all major browsers your users use, so you'll get early notice of these types of issues. There's not any alternative approach besides never changing any installed feature, which is a possible approach, but not the one we as a species are taking.
Ideally, people would. But for most, a browser breaking such a basic feature is just not on the radar. I would imagine there is a good number of extremely simple sites (or parts of sites that you'd easily assume wouldn't ever need maintaining) that this breaks. IMO, breaking a feature requires it to either be pretty much never used, have a very good reason, or be heavily publicized. This change has none.
> which you have to abide by using google.com or any other Google web property

When did my web site become a Google property?

> When did my web site become a Google property?

It isn't. Not sure that's relevant to the discussion though. We're talking about Google's TOS, which presumably the person at the start of this thread is concerned about having to accept to get an origin trial token.

Seems relevant to me. Requiring a website owner who may have no relationship with Google to enter into a contract with Google in order for their website not to be broken for their users -- I think that's antithetical to the idea of an Open web.

Google is not offering any kind of service for that contract, other than that they won't break exiting functionality for your website, a thing that they have no ownership over. I feel it's problematic for a user to visit a website and essentially get told "the site will no longer work for you because the owner wouldn't sign our TOS."

TLDR, I don't like the philosophy that a website operator needs to get Google's permission for their site to work in Chrome.

There will always be things about browsers that are different from vendor to vendor. It seems impractical to expect that you would be able to access all the relevant resources without going to the vendor's website.
> It seems impractical to expect that you would be able to access all the relevant resources without going to the vendor's website.

I'm not sure I understand what you're trying to say here. Going to Google's website or looking at Chrome documentation is a lot different than signing a TOS with them.

And Chromium is Open Source, so I don't need to sign a TOS to test V8 changes or get access to Chromium features.

The only reason a TOS is coming into this is because Google artificially inserted one in front of an origin trial that realistically should be handled based on some kind of request header or at most as a signup form with a DNS check for owner verification. None of that should require a legal contract or Google account.

TLDR, I don't like the philosophy that a website operator needs to get Google's permission for their site to work in Chrome.

I absolutely agree with you and think that we need a term for (the opposition to) this: browser neutrality.

> What's weird about the TOS?

My website has nothing to do with Google. Why should I have to agree to a contract with Google just so people can use my site?

Would you be fine with Facebook also forcing agreement with a contract just to view a completely third party website in a web browser?

There's an ongoing conversation that has lasted about four years on https://github.com/whatwg/html/issues/2791 regarding whether or not browsers should implement `<include>`, (think client-side SSI, php's `include`, ngInclude, or similar fragment import functionalities from different software) which basically comes down to the four(?) editors (Mozilla, Microsoft, Google, Apple) not liking it.

I noted that it's the most commented on issue in the whatwg/html discussion space, and for good reason.

It's just tiring to read through discussions where a small number of people control web technologies. Oh well.

At this point HTML is quickly turning into not a markup language
I miss writing HTML instead of telling Javascript how to create the HTML that I would use. I preferred JQuery's $('<htmlcodegoeshere>') vs document.createElement('element').append(document.createElement()) bullshit
even when you do that, it's at least a markup language, I just don't understand how include fits into the semantics
Might be worth looking at Vue and Svelte.
nah, now i just hand it to the frontend aliens that like that stuff.
> four(?) editors (Mozilla, Microsoft, Google, Apple) not liking it. [...] a small number of people control web technologies

Isn’t this expected? The other people can say whatever, but the final decisions will be made by people committing the code into major browsers. If they say “no, we won’t implement this”, what can others do?