For most JS served by CDN, you can (and should) use Subresource Integrity to verify the content. At least the last time I was involved in an AMP project, Google considered AMP to be an "evergreen" project and did not allow publishers to lock in to a specific version.

Long term versions are now supported, so publishers can lock in a specific version.

Publisher hosted copies are in the pipeline, as I referenced in the parent comment. My choice of verbiage was a bit confusing it appears.

I don't think it's your wording that's confusing. You are contradicting the AMP documentation.

AMP's documentation seems to indicate that the LTS is stable only for one month (new features released via the same URL each month), and so is not compatible with SRI (see https://github.com/ampproject/amphtml/blob/master/contributi...)

You can specify a version (ie, https://cdn.ampproject.org/rtv/somenum/v0.js), but the AMP validator complains about that.

> The same could be said of any CDN hosted javascript library

Yes, and? What’s your point? It’s actually a security weakness to include third party JS. The whole thing runs on trust.

What's an open intent? Where is this documented?

AMP spec: https://amp.dev/documentation/guides-and-tutorials/learn/spe...

"AMP HTML documents MUST..."

"The AMP runtime is loaded via the mandatory <script src="https://cdn.ampproject.org/v0.js"></script> tag in the AMP document <head>."

Do a whois on ampproject.org:

"Registrant Organization: Google LLC Registrant State/Province: CA Registrant Country: US Admin Organization: Google LLC"

Note that jQuery, as mentioned in some GP comment has no such requirement. Google AMP is quite unique in this regard. This is NOT some general CDN type issue. Also...agreed, WTF is "open intent"?

Note "open", i.e., unresolved. Perhaps in a less positive light, "how to enabled signed exchanges/AMP without controlling it".

Correct. Open as in not resolved yet, but intended to be resolved in the future.

You missed the required part.