You should take a hard look at what you're doing. It's breaking the web by enabling Google to embrace, extend, and extinguish. AMP and Signed HTTP Exchanges aren't agreed upon web standards, and Mozilla calls the technology harmful.

https://mozilla.github.io/standards-positions/

https://www.zdnet.com/article/former-mozilla-exec-google-has...

I dislike getting AMP pages, and when I'm served one I can usually find the URL to get to the proper page manually.

Does Real URL mean that I can no longer do this? How can I find the URL of the page I really want to see?

The URL is now where you'd expect it -- in the address bar.

Copy and paste it to a new tab and you're off to the races.

What happens if you just focus in the address bar and hit enter or hit the reload button? Either result, the user won’t actually be sure where it’s loaded from.

AMP is an objectively bad thing, designed to further strengthen googles control over the web.

I’ll be encouraging my customers who currently do or may have used cloudflare to use alternative solutions from now on.

Edit: removed weird extraneous “that”

How does the browser know to grab the real page or the amp version? I never want to load an amp page in my browser and out of respect for others privacy I never want to share a link to an AMP page. How can I do this with the new proposal?

Look for /amp in the URL.

So in order to get to a non-AMP version of the page, you have to duplicate the tab? The content will be different but the URLs will be the same? How is any ordinary web user supposed to understand this?

Correct, it's essentially the same as it is now, but easier as you don't have to worry about removing the "google.com/amp" prefix.

I assume this means I’ll be able to use a browser extension to catch AMP requests and convert those requests into traditional requests?

Not making an AMP judgement in this comment, just asking if the technical capability exists.

I'd be curious how an extension would know it's an AMP page in this new situation. Is there some new extension API or response property exposed?

Will this load an uncached copy of the AMP version, or the canonical URL as specified by `<link rel=canonical>`?

That is up to the website, some elect to use separate URLs for their AMP content, others serve a different version based on the requestor, others might be AMP-native and not have another incarnation.

How is it up to the website? Can they put a URL in their signed package for the browser to display that won't load the same content if you copy it and paste it into a new location field?

OK, thanks.

Thats a good question can you still access the orginal page then.

Not sure why I got down voted, but the question I responded to has been answered. The URL structure still has AMP in. So one can access the original page at least.

Couple implementation questions:

Who's javascript/cookies run in a real URL amp page, if any?

What happens if I hit refresh, does it reload the AMP page or the real page?

Can a webpage that isn't Google use real domain AMP pages? In that case, can their javascript influence the page at all? (ie change the look, put elements over it, make http requests)

Good questions:

> Who's javascript/cookies run in a real URL amp page, if any?

The document operates as the signed origin, so cookies, CORS etc all operate as the signed origin (the one in the URL bar). The HTTP request is made using the request URL's origin however, so the server delivering the signed exchange has no cookie access to the signed origin's cookies.

> What happens if I hit refresh, does it reload the AMP page or the real page?

A refresh will cause the browser to make a normal HTTPS request to the origin in the URL bar. A refresh works identically to what it has in the past, essentially.

> Can a webpage that isn't Google use real domain AMP pages?

Yes. It is a spec that browsers can support, and any site can use. There is nothing Google specific, or even AMP specific, about the specification.

> In that case, can their javascript influence the page at all? (ie change the look, put elements over it, make http requests)

No. Conceptually, you can think of a signed exchange as a 301 redirect to a new URL which has already been cached by the browser (so there is no 2nd network event). The cache was populated by the contents of the signed exchange, assuming the signature validates.

Could Cloudflare accept a request header that would load up the full page instead of the AMP one? I suspect many people would use such a feature, and it would also be a good way to indicate to Google (and now it seems, Cloudflare as well) the dislike of AMP.

While it would present a fingerprinting vector, I would likely enthusiastically use a browser extension which effectively disabled AMP.

So is this basically the server okaying a replay attack? I'm looking through the technical post but it hasn't clicked yet.

That's kind of a funny way of thinking about it, buy yes? Loading an AMP page is (hopefully) an action which isn't mutating any state, so I would say it's more similar to how a CDN works. You decide you are interested in having a cache respond to a given request in a specific way, and it responds to requests which look a certain way with that response.

In this case it's significantly more secure though, as the exact request and response are signed and a third-party you trust (your browser) is deciding if that signature matches.

Analogy: Squid caching with a signature from your SSL certificate that proves it was valid as of when you signed it, so that the browser can trust the Squid cache and display the URL that’s in the signed plaintext with a domain matching that of the certificate that signed the cache blob.

Today’s browsers trust all user-configured proxies implicitly and no other proxies at all, so providing a signed copy of the GET-only AMP content, it can be safely cached (the “replay attack”) without needing to trust the cache, because it’s signed plaintext.

> okaying a replay attack

When you permit a proxy to replay your content, it's just caching. It's not an "attack." (If the proxy can replay your content without your permission, that would be an attack.)

I believe AMP required inserting a piece of Google controlled and hosted JavaScript in your content from the very beginning. So the cat was pretty much out of the bag on this already.

So if you block this Google JS, you cannot access said AMP page? Does AMP implicitly mandate users subscribe not only to said content provider but the third-party AMP host?

Yes, you have to include it.

"AMP pages must...Contain a <script async src="https://cdn.ampproject.org/v0.js "></script> tag inside their <head> tag."

https://amp.dev/documentation/guides-and-tutorials/start/cre...

Their special tags[1] won't render without it, and I suspect Google won't include it in their SERPS if it's not valid AMP.

[1] https://amp.dev/documentation/guides-and-tutorials/learn/spe...

They're certainly not doing it without the website owner's permission. It's disingenuous to call it an attack.

Yes, that's fair. I meant more in terms of ceding control...that's a prerequisite for AMP, and always has been.

Is there any notion of expiration? If I present a signed page to a crawler, what’s to stop them and their partners from serving that page on behalf of my domain for all eternity, and browsers presenting it as valid and authorized by my domain? From retractions to right-to-be-forgotten, there are a billion reasons I would want the ability to disavow cached content.

Yes: https://wicg.github.io/webpackage/draft-yasskin-http-origin-...

What can I do to stop the spread of this harmful technology or at least never get served amp pages?

Very constructive comment here. Perhaps you can reword to better understand the value or express why you feel this is harmful technology so OP can help address it.

Personally, I never want to see an AMP page and its ugly design and shitty controls. How do I make this happen? Is there something I can do that will make Cloudflare simply redirect me to the real web page instead?

It sounds to me like you're talking about the grey bar at the top of pages served from the AMP cache? This change is about using Web Packaging to remove that bar.

(Disclosure: I work at Google)

I think he, along with many others, wants Google to stop pushing this garbage on the internet.