>The promise of the AMP (Accelerated Mobile Pages) project was that it would make the web, and, in particular, the mobile web, much more pleasant to surf.

That's, ostensibly, the goal, but anyone with an independent mind can tell it's just about control.

>It was particularly aimed at publishers (such as news organizations) that wanted to provide the best, fastest web experience for readers catching up on news stories and in depth articles while on the move. It later became valuable for any site which values their mobile performance including e-commerce stores, job boards, and media sites.

What a harrowing paragraph.

>As well as the AMP HTML framework, AMP also made use of caches that store copies of AMP content close to end users so that they load as quickly as possible. Although this cache make loading web pages much, much faster they introduce a problem: An AMP page served from Google’s cache has a URL starting with https://google.com/amp/. This can be incredibly confusing for end users.

This wasn't an issue before TLS everywhere was pushed, was it? The same organization that pushed for encryption, no matter how useless, Google, is now there to solve the problem of caching encrypted pages, centrally of course.

>But the problems with the AMP cache approach are deeper than just some confusion on the part of the user. By serving the page from Google’s cache there’s no way for the reader to check the authenticity of the page; when it’s served directly from, say, the BBC the user has the assurance of the domain name, a green lock indicating that the SSL certificate is valid and can even click on the lock to get details of the certificate.

There's already no foolproof way to do that. Rather than checking that it's actually BBC and BBC has verified what it's delivering, you instead ask a third party if this is the BBC and if what it's sending is true.

>That signature is all a modern browser (currently just Chrome on Android) needs to show the correct URL in the address bar when a visitor arrives to your AMP content from Google’s search results.

So, just as with ''DNS over HTTPS'' and other nonsense, this is yet another thing they want to pile on.

>Importantly your site is still being served from Google’s AMP cache just as before; all of this comes without any cost to your SEO or web performance.

Only fools and cretins care about SEO and ''web performance'' is solved by not having so much JavaScript and actually bothering to optimize images you send.

>Brand Protection: Web users have been trained that the URL in the address bar has significance. Having google.com at the top of a page of content hurts the publisher’s ability to maintain a unique presence on the Internet.

Not violating people already trained is very important.

>Easier Analytics: AMP Real URL greatly simplifies web analytics for its users by allowing all visitors, AMP or otherwise, to coexist on the same tracking domain.

Anyone using anything more than HTTP server logs, which are already too revealing, is likely a fool.

>Increased Screen Space: Historically when AMP was used room would be taken for a “grey bar” at the top of your site to show the real URL. With AMP Real URL that’s simply not necessary.

This sentence is only possible due to a dearth of independent implementations, which communicates a great deal about this nonsense. Also, it's nice to see Google beginning to kill URLs as it wanted to; lying in the UI is a good first step.

>Content Signing: By relying on cryptographic techniques, AMP Real URL ensures that the content delivered to visitors has not been manipulated protecting the sites and brands it is used on. It’s now not possible for any external party to add, remove, or modify the content of a site.

Remember when Cloudflare was spewing private information all over the Internet?

>We are also taking this opportunity to sunset the other AMP products and experiments we have built over the years like Ampersand and Firebolt. Those products were innovative but we have learned that publishers value AMP products which pair well with Google’s search results, not which live outside it. Users of those older products were informed several weeks ago that they will be gradually shut down to focus our attention on AMP Real URL.

Don't worry about this being shut down for the next big thing, though.

>Our motivation is the same as for offering CDN or SSL services to millions of customers free of charge

You mean subverting the Internet through increasing centralization and also enabling mass-spying by the perversion of the very encryption that's ostensibly so important?

Does anyone actually think Cloudflare isn't a US government operation? They have so much hardware and they get so much support from these other companies that we know are paid off by the government.