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.