It is not a requirement for AMP. CDNs now let you roll your own domains on the AMP standard: https://blog.cloudflare.com/announcing-amp-real-url/

Bing also uses the AMP standard: https://blogs.bing.com/Webmaster-Blog/September-2018/Introdu...

> It is not a requirement for AMP. CDNs now let you roll your own domains on the AMP standard

All these certificates do is make it so Google's browser (and only Google's browser) will mask the fact you're on Google's domains if you sign the file a certain way.

If anything, this shows more anti-competitive practices -- they're adding features into their browser that specifically benefit a features of their search engine.

That's not true. CDNs also use their own non-Google domains and infrastructure for AMP hosting:

https://amp.cloudflare.com/

Effectively 0 AMP sites are using anything other than Google's CDN.

Is this link using Google's CDN?

https://amp.businessinsider.com/lambda-school-online-coding-...

Yes, sites just host the original copy submitted to Google. You can see all the resources are loaded from https://cdn.ampproject.org

If you visit the page from search results (which is the only place it would be linked) then it would never leave Google's domain.

Here's the actual URL used from search results: https://amp-businessinsider-com.cdn.ampproject.org/v/s/amp.b...

But as long as it's possible it doesn't qualify as lock-in.

You don't need lock-in to be anti-competitive. The requirement of extra work to implement AMP to get that higher search results page placement is the issue.

At which point pushing for new technologies as a private entity is anti-competitive vs moving technology forward?

If the criteria is just "needs extra work" then unfortunately almost nothing can change and we're all going to live with the existing technology. Change inherently has friction and requires "extra work" with the hope that's an investment which provides returns long term.

In other words, say you are a large Internet company that is trying to improve web page loading times. You profile why most web pages are slow and identify issues. You publicly report on those issues and develop guidelines and criteria. Nobody bothers because "extra work". You develop new technology that directly addresses those issues, this technology works within the existing environment but it requires both client and server support to be most effective. Do you think anyone cares? No, because of "extra work". That's why there needs to be incentives. Now you have a "penalty" for not doing that "extra work". You can file it under "it's anti-competitive" (maybe it is) but if you do the "extra work" then suddenly the anti-competitive part works for you, not against you. IMO that's why it's not anti-competitive.

Other examples: why do you think there are so many people that complained when iPhone released with Flash reader? "extra work". Similarly when it removed the audio jack. Change is friction and friction is extra work. But most of the time that's not anti-competitive...

Let me explain based on my 15 years of adtech experience:

HTML is already fast (see HN for an example). HTML is already universal across devices and browsers. HTML is already published and easily cached for billions of pieces of content.

AMP is a fork of HTML that only targets mobile browsers specifically linking from Google search results. It's useless on its own, but AMP is required to get higher placement on search results pages, so publishers are effectively forced to spend technical resources to output an entirely new format just to maintain that ranking.

If Google wanted faster pages then it can do what it always does and incentivize that behavior by ranking results based on loading speed. These signals are already collected and available in your Google webmaster console. There's nothing new to build, just tweak ranking calculation based on existing data. Sites would get faster overnight, and they would be faster for every single user because HTML is universal.

Do you know why they didn't do that? Because it's the ads and tracking that's slow, not the HTML. Google's Doubleclick and Google Analytics are the biggest adserver and tracking systems used on the web. This entire AMP project is created to circumvent their own slow systems. It creates more work for publishers while increasing data collection by running a "free" CDN that never leaves a Google-owned domain and thereby always supports first-party cookies. It's a perfect solution to protect against anti-tracking browsers and why Chrome now will also block 3rd-party cookies, because it won't affect AMP hosted on Google domains.

This makes sense. With all that and browser fingerprinting and accounts and "other" mechanisms, do they even need cookies anymore?

First party storage won't be affected without some major AI tech in browsers so cookies are still the best deterministic connection, especially since most people are logged into a Google service already (gmail, chrome, android, youtube, etc).

Probabilistic techniques are used for anonymous users or environments like iOS Safari that are very strict.

So the user sees your URL, you're getting the revenue from the ads that are shown, sharing will share your URL, your statistics work flawlessly.

In other words: if it behaves exactly as a page hosted on your site (just faster), why do you care?

I'm getting the impression that HN users care a whole lot about seeing the request in the nginx log they are tailing.

Well, as a user, I care about not announcing loudly to Google every single step I take on the web.

Then why are you searching on Google? That's where you would see an AMP page served from a Google AMP cache. If you searched on Bing, you would get AMP pages served from a Bing AMP cache instead.

In the past year, I've seen amp pages increasingly often linked from all sorts of places (reddit, FB, here, etc) besides Google's search results.

AMP pages hosted by the publisher, Google's AMP cache, Bing's AMP cache, or some other company's AMP cache? GGP was complaining about sending any information to Google. Only one of those options does so.

I am obviously not.

It's not always faster. There are plenty of performance and usability issues with AMP pages, not to mention all the extra development effort needing to maintain a different version of the site just for a few mobile browsers.

It's anticompetitive af.

The content is still served from their CDN regardless of the domain. There is no way to serve AMP sites from your own servers and appear in the search carousel among other AMP articles.

Google is strong-arming the entire web to switch to AMP in order to increase their control over the distribution of content, and to be in a better position for tracking users.

The fact that Microsoft and Cloudflare have joined the party does not change the fact that you're about to lose control over your own content if this is not stopped.

That's not true. CDNs host AMP sites on their own domains and infrastructure, independent of Google:

https://amp.cloudflare.com/

By "their CDN" I meant Google, Cloudflare and Microsoft. Can we set up our own CDN to serve our own content from our own servers and receive the AMP badge in search results?

Please disclose your affiliation to Google either in your bio or in comments, and don't post the same comment in multiple places.

> Can we set up our own CDN to serve our own content from our own servers and receive the AMP badge in search results

This...doesn't make sense. You lose the value of a CDN (both to you and to the consumer of your content, in this case Google and the end user) if you're rolling your own.

It no longer makes sense to be able serve our own content without it being pushed down in search results?

We were talking about CDNs because your collegue mentioned AMP CDNs, but the main point doesn't change: we cannot serve our own content from our own servers and get the same placement in search results as AMP content, even if our content loads verifiably fast and is as performant as an AMP page on the client.

> We were talking about CDNs because your collegue mentioned AMP CDNs

I have no clue who bdeurst is. They certainly aren't a colleague of mine.

> even if our content loads verifiably fast and is as performant as an AMP page on the client.

Can you explain to me how your page load time is 0ms? My understanding is that a correctly functioning AMP-cached page will load for the user in a whopping 0ms, because it can be preloaded.

The entire design of AMP starts from a fairly straightforward premise: "How do we reduce (user-visible) page load times to 0, safely, cross origin?" If your pages user-visible loading time is longer than 0, you're failing to keep up with AMP.

AMP pages are preloaded, that's how your get the 0ms load time. If Google would instruct the browser to preload other search results the same way, those would also be available in 0ms when the user accesses them.

See my statement about secure, cross origin preloads. You're asking a search engine to XSS attack its own users.

I think the correct term I was looking for is prefetching. That's a secure way to tell the browser to start loading search result links in the background.

> That's a secure way to tell the browser to start loading search result links in the background

prefetching isn't private cross origin:

> Along with the referral and URL-following implications already mentioned above, prefetching will generally cause the cookies of the prefetched site to be accessed.[1]

IDK about you, but I'd generally prefer that my cookies and IP not be exposed to all of the links that happen to be in the first page of search results.

[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefe...

Browser specs can be improved, and new ones introduced. And even if safe prefetching is deemed technically impossible, the question remains: should we give Google and a handful of other companies disproportionate control over how we publish and consume content, for 50ms of load time?

> Browser specs can be improved, and new ones introduced.

Yes, for example Signed Exchanges, which on a technical level solves all of the problems of rel=prefetch (and a number of the problems with AMP, like link pasting and copying).

> Should we allow a handful of companies to be pinged every time we load a page on the web

I'm hopelessly confused here: you're only going to "ping" one of the handful of companies if you were referred by that company. (In a world with signed exchanges) You're not going to come across an AMP-cache link organically. You'll navigate to example.com directly, without anyone except example.com (and your DNS provider) knowing. The cache provider will only know if you navigate to the cached site via the cache provider. Concretely, you don't go to the Google amp-cache unless you're navigating there directly from Google's search results. Same for Microsoft/Bing.

So if your metric is

> Should we allow a handful of companies to be pinged every time we load a page on the web

Then yes, absolutely, because nothing changes!

Edit: To address your other question,

> should we give Google and a handful of other companies disproportionate control over how we publish and consume content, for 50ms of load time?

Alright: how is AMP materially different from <whatever other algorithmic choices rated search results before>?

You seem to be claiming that AMP is harmful to someone but who? It's not harmful to competitors or to end users, and its only harmful to developers if you make the most strained argument.

My premises here are that users actually prefer AMP results. You may not, but my understanding is that most users do. So from the perspective of an end user browsing the internet, AMP leads to an improved experience.

So it's good for users.

No one has yet been able to explain to me how its actually harmful to a web developer who now has an incentive to make AMP-compatible sites. Like sure, you now have to work with a framework you may not like, but that's not a compelling argument when people are claiming that AMP is a threat to the sanctity of the internet.

So it's not like bad for web developers, it's just sort of a lateral move.

That leaves competitors to the giants. But AMP is an open standard, and DDG could, if they wished, implement an AMP cache themselves today and it would just work. And they'd, if anything, benefit from the bigger players pushing that ecosystem. There's the potential for abuse via the caches.json registry, but the AMP project is aware of this and notes that the registry could be decentralized using Subresource Integrity or similar, if such a standard was adopted[1].

So again: I'm confused by how exactly it's bad, beyond the "I am forced to develop in a way I don't want to if I want to appear near the top of the search page", which isn't new.

[1]: https://github.com/ampproject/amphtml/pull/18495/commits/c5d...

I've actually removed that second question before I noticed your answer, because I knew you would then skip over the first one. Feel free to address the main point I was making in all my posts in this thread, whenever you feel ready.

> So if your metric is

Google being pinged obviously isn't my main metric, as you can see from all my posts in our discussion. My main concern is that publishers will be forced to use specific publishing mechanisms (AMP, Signed Exchanges) to appear at the top of Google Search results. That loss of control puts publishers in a vulnerable position, and hurts innovation across the web.

> Then yes, absolutely, because nothing changes!

Everything changes. Google's influence and control won't end at the moment the user navigates away to a top result on Google Search.

I updated the prior post, but to be a bit more concrete, what differentiates AMP signed exchanges from, say, HTTPS?

Google could serve an older version without the user knowing.

The signed exchanges protocol requires that the content be signed with a key with a short expiry date (< 1 week), sites are free to make it shorter. In extreme cases, the providing site could sign with an expiry of < 1 day or even something like 1 hour.

And iiuc, sites are still free to revoke their certs. So this is actually probably more secure compared to something like https in that regard.

[0]: https://github.com/WICG/webpackage/blob/6cc3237b36c2f9ce7534...

I see what you're saying but im not sure that's a problem - how many people are building CDNs in their garages that need to be certified?

Also, everything I say on HN reflects my own opinion and not any organization, which is what my profile states. I do not hide behind an anonymous username precisely for this reason. Poisoning the well by doxxing me doesn't change how the AMP standard works for CDNs either, and only serves to derail the conversation.

>Everything I say on HN reflects my own opinion and not any organizations, which is what my profile states

Sorry, but I agree with dessant. Your profile doesn't disclose your affiliation and nor do your comments. It's absolutely relevant to the discussion, because whether you want to admit it or not (or try your best to act neutral), your day job will have some influence over your opinions on these sort of projects.

You're right that it doesn't change objective facts about the specification, but I think it's misleading to suggest that, in general, external third-party CDNs are first class citizens in the AMP ecosystem when they're not treated the same within search.

Because the Department of Justice doesn't enforce anti-trust law anymore. Read the book "Chickenshit" for more details.

Also what is the technical benefit? On android it feels like a downgrade

It seems faster for me across devices but there’s usability issues, at least on some sites/pages. In my experience “find on the page” is spotty or impossible on mobile sometimes.

What makes you think it feels like a downgrade? AMP results seem to, on average, load faster with a better UI to me.

Not sure why this is being downvoted. I encourage people to visit the non-AMP version of smaller news providers.

Enjoy the popups, video ads, autoplay, bloated sizes, etc.

Whenever I get an AMP page, I always go to the non-AMP version, even for smaller news providers.

I find the non-AMP version to be superior every single time, but I use NoScript so I don't see the popups, video ads, autoplay, etc.

If you use adblocking addons you don't get many of those.

Or even reader mode - I don't mind flashing the cruft for a few seconds while I turn it on, and it's the best of all worlds. The site gets their ads (briefly) loaded, and I get a clean page to read.

AMP isn't being forced on websites, they choose to enable it or not.

That's an arguable point if not enabling it means lower rankings on search... Which is problematic when both are being offered by the same company.

You either choose AMP and appear in the search carousel at the top of search results in the biggest search engine in the world. Or you choose not to implement AMP and you don't appear there.

Your "choice".

Cake or death.

Yeah and death row prisoners choose their last meal /s