It might discourage webmasters from adopting AMP though, if they have the expectation to lead the visitor to the homepage or other articles.
This is akin to an ISP injecting their own little optimization toolbar into pages rendered to the user, except that cert pinning isn't even an option here, since Google is doing the content re-writing at the app tier. They even manage to keep the browser security icon green, creating the at-a-glance perception that the data provenance can be trusted!
If Google edge caching really is critical, then I'd rather see an architecture in which the AMP content is signed by the originating site, and the signature is looked up and validated client-side. This might incur a bit more of a performance hit for sites that are being overwhelmed, but really, that's as it should be -- as an end user, it's surprising that my AMP results are essentially a Google cache. And it would seem that Google goes to good lengths to make the look-and-feel appear browser-like, instead of calling out the cached nature of the response.
Why would a cached website be shown looking different from a non-cached one?
Typically, cached web pages come out of edge caches, either maintained by a CDN selected by the content provider, an end-user's ISP, or by a box on the local network. In this case, Google -- the search engine -- is fundamentally changing the nature of how the user obtains the third-party search result content.
IMO this is very different than my company or ISP doing some edge caching. It's different because it is much more of an opt-in sort of relationship, and, more importantly, because it's decentralized -- if Comcast starts to muck with search result content, Verizon users will notice the discrepancy. If Google takes advantage of their monopoly position and alters AMP content, nobody except the content providers will be the wiser.
I'd imagine that end users who don't trust Google aren't using Google.
> There's no real indication to an end user that that data is coming out of Google's caches rather than from the content provider.
Users who care can see the URL and the domain for which the cert is signed. Most users do not care.
> IMO this is very different than my company or ISP doing some edge caching. It's different because it is much more of an opt-in sort of relationship...
I don't see why I can't substitute "Google" and "Bing" for "Comcast" and "Verizon" in your example.
For that matter, at least in the U.S., it's a lot easier to switch out my search engine than my ISP if Comcast starts to muck with result content. FWIW, Verizon already redirects failures of domain name resolution to itself. I don't like it, and there's not much I can do about it if I want Internet around here.
> If Google takes advantage of their monopoly position and alters AMP content, nobody except the content providers will be the wiser.
That's a fair concern, but the day Google does that is the day a media firestorm blows AMP out of the water as a trustworthy tool.
And in particular, it looks (at a quick check) like the google hosted files are in a very predictable location, so it should be easy to write something to check both that version and the hosted version against each other to monitor for discrepancies.
Except Google use to just guide your to the content, you just had to trust them to give you the best possible answer. Now you have to trust they have the real one too.
> Users who care can see the URL and the domain for which the cert is signed. Most users do not care.
Most users do not care if their passwords are stored in plain text, or if a bridge they cross has been built by a proper engineer. Consumer ignorance is not a valid reason for shady practices.
AMP's purpose is to deliver content at minimal bandwidth and latency. Requiring the client to side-channel to the originating server (that can be God-knows-where relative to the requesting client) defeats the purpose of creating a system for low-bandwidth users to quickly fetch and display content on mobile devices.
It's hypocrital to bill AMP as an improved mobile experience, while sticking a big button at the top. Also hypocritical to penalize sites for scraped, dublicate content, while doing the same themselves.
As I wrote before, it's "more of a mutually-consented handholding with small amounts of arm-twisting" [2].
[1] https://www.ampproject.org/docs/reference/components/amp-ad#...
Most users do not actually care what the URL bar says. We know this because of the number of people who get to Facebook by searching for "Facebook".
> Google is not stealing traffic but it is stealing
> content
>The real cost of a website is not hosting it but filling it with things people want to read. Content creators will want to get benefits such as ad revenue to compensate for their effort.
Google doesn't create AMP pages for you - the content creator does. If the content creator wants to insert ads then they can do so via AMP.