Comment by AlexandrB | Hacker News Reader

Comment by AlexandrB | Hacker News Reader

This is a "solution" to a "problem" that AMP itself created. And in the process it creates additional complexity[1] and a new potential revenue stream[2] for middlemen providing a service that shouldn't be necessary in the first place.

Astounding.

And oh yeah:

> AMP Real URL is only supported in the Chrome browser at this time, but we are optimistic it will be supported more widely as its benefit to Internet users becomes clear.

Who needs web standards, right? [3]

[1] Especially egregious because it's making SSL identity validation even more complex than it was before. I'm sure this will make getting security "right" even harder.

[2] Or in this case a new barrier to competition:

> After speaking with publishers and with Internet users, we have decided not to charge for AMP Real URL. This is not because our customers haven’t been excited or willing to pay for it, AMP makes up a huge component of many site’s traffic. Our motivation is the same as for offering CDN or SSL services to millions of customers free of charge, we are here to help build a better Internet and improving AMP is a huge step in that direction.

Edit: [3] dfabulich (below) has correctly pointed out that this is in the process of being standardized: https://tools.ietf.org/html/draft-yasskin-http-origin-signed...

Despite this, Firefox has currently marked this proposal as "harmful" (https://mozilla.github.io/standards-positions/). It seems to me as though Google may be ramming this one through despite objections.

> Who needs web standards, right?

No one needs to follow web standards when one browser gets so big that it can completely dominate the technology and the corporation that runs it can force anything they want down everyone's throats! If you don't want to see things like this happening (and you shouldn't, AMP is a disgusting technology), stop using Netscape, err, I mean, Chrome.

Microsoft is in favor of it. The Chrome team generally ships stuff if at least one other major browser vendor approves.

I'm aware of that, but it doesn't make me feel any better about it somehow.

Does Microsoft still count as a major browser vendor, given that they'll be shipping a blink-based browser? Of course, the same thing might be said back when Chrome was using Webkit too… and I think it was.

The major browser vendors are:

  * Google (Blink –> Chrome, Edge)
  * Apple (WebKit –> Safari)
  * Mozilla (Gecko –> Firefox)

Given that Microsoft has itself formally announced that EdgeHTML is abandonware, they have no ability to vote on future browser standards. That's not an opinion, it's the unavoidable consequence of not being the developer of a web browser engine. Personally I wish they still had a vote.

Chrome had a vote when they were on WebKit.

If your browser has a bunch of users, and if you can (and do) opt to block features in your fork, you're a major browser.

Microsoft has ripped a fair amount of stuff out of Chromium already. https://www.theverge.com/2019/4/8/18300772/microsoft-google-...

None of those Chrome features ripped out by Microsoft are web standards or web standard proposals. They are nearly all application support features or user conveniences; most of them tied in some way to the Google ecosystem.

Google maintained their own fork of WebKit with countless feature deviations from the main tree. If Microsoft builds a track record of maintaining their own fork to hold back or modify actual web standard proposals written into the Blink engine then I would agree—they would regain eligibility into that list.

On a similar note, MS is/will offer many of those features themselves tied to ms/live services.

Of course, I'd rather it this way as MS can at least have a browser that keeps pace with the rest of the world. Edge would be about on parity twice a year or so, and often the biggest of my headaches lately. Fortunately no longer having to support any IE currently (only browsers with async function support).

Does the ability to do so give them a spot on the list, or do they have to flex the muscle before they can prove that it's there?

Username checks out. :-)

The list is descriptive, not prescriptive.

If they haven’t flexed their muscle, it doesn’t matter if they’re on the list or not. If they do assert that influence, they’re on the list.

> Who needs web standards, right?

This new thing (signed HTTP exchanges) is an IETF draft. https://tools.ietf.org/html/draft-yasskin-http-origin-signed...

As usual, Chrome is the first browser to implement this, but they're participating in the normal standards process. (Microsoft is in favor. The Chrome team generally ships stuff if at least one other major browser vendor approves.)

I stand corrected. But I still think that AMP and Google in general are bad for an open, competitive internet.

They do participate in the standards process, and that's great, but it doesn't also mean they don't subvert it or shove tech down everyone's throats until it becomes a defacto standard that you have to implement if you want to stay competitive.

But Firefox and Safari aren't on board. I thought everyone had agreed that browser flags were the best way to implement features that weren't actually approved/standardised yet

Turning it on when they know there's no consensus is breaking the web standard

Normally I'd rush to Chrome's defense here (see my post history) but I have to agree with others about Chrome kind of breaking the process here. Other browser vendors have large concerns with this spec, so it's quite surprising that it's shipping at this scale.

Doesn't surprise me in the slightest. Chrome has done this before, e.g. with QUIC.

This doesn't mean anything though, they all crap out rfcs whenever they have a new feature to push. And they all usually agree with what each other pushes, but even if they don't, the browsers will just forge ahead however they want. Standards are diplomatic cover.

A draft written by a google employee.

I'm curious about the flipside, what's the steel man argument for AMP?

About signed http exchanges, the new feature being announced and used by amp:

Say you have a site that links to other pages on your site, and you want the links to be instant. After a user loads a page on your site, you can have javascript on your page preload the content of the links on your site, so when the user clicks on one, you can instantly update the URL and show the new page. (You could even do something clever like only preload the content of links that are visible on the screen currently, or that the user is moving the mouse toward.)

The above only works on links within your own site, because 1) there's no way your javascript can render something onto the screen with someone else's domain in the URL bar, 2) if the user's browser is pre-fetching the content directly from the linked sites and if users can post links to arbitrary sites on your page, then someone can get the IP addresses of all of your visitors by posting a link to your site, which may be preloaded by everyone's browsers who visit your page, regardless of whether users actually click the link, and 3) the user already has an open connection to your site, so preloading would be quickest if the data came from your site instead of potentially dozens or more of other sites. Point #1 could be solved by browsers implementing the prefetching logic, but that doesn't solve points #2 and #3.

Now imagine that your server could download signed and packaged versions of all of the pages linked to on your site, and then have your javascript preload that data from your server into your users' browsers, in a way where the users' browsers can verify the signature of the data to know that it really came from the linked sites and display it if the user visits any of the links on your site. That's what signed exchanges enables.

Does the origin site lose advertising and analytics?

Not necessarily, the payload can contain javascript that will run if the content is actually loaded. This would allow most advertising and analytics scripts to continue to work.

This is Google. If this technology weren’t compatible with their ads and analytics, they wouldn’t push it.

Worth noting that Mozilla's current position on this standard doesn't really make sense: https://github.com/mozilla/standards-positions/issues/29#iss...

There may indeed be valid issues with the standard, but their current rationale for marking it as "harmful" isn't technically sound.

Reply on news.ycombinator.com