4 ms·

The JS include is something you add to your own HTML. Couldn't you add an SRI hash in here? <script async src="https://cdn.ampproject.org/v0.js"></script> htt

The JS include is something you add to your own HTML. Couldn't you add an SRI hash in here? <script async src="https://cdn.ampproject.org/v0.js"></script> https://cdn.ampproject.org/v0.js"></script> You could also serve the JS from your own domain if you prefer. Similar to Google's cache, it's something available as an option to you. Regarding the Amp standard, that is indeed something controlled by Google. Particularly as it pertains to the SERPs. But because it's open you also have the option to fork it, or write a completely different implementation if you desire. If you'd like to modify Amp but still stay within their standard, you can submit a PR as well. It looks like about 75% of PRs are merged. https://github.com/ampproject/amphtml/pulls https://github.com/ampproject/amphtml/pulls The Amp standard is locked down, but the technology isn't. Which is not too dissimilar from HTML itself.

callahad 10y ago
That's how it should work, but now how it actually works. From https://github.com/ampproject/amphtml/issues/534#issuecomment-273273590 https://github.com/ampproject/amphtml/issues/534#issuecommen...: > "AMP is an evergreen JavaScript library. We will not allow users to lock themselves into a particular release." Which completely precludes using SRI. Further, pages serving their own copy of the JavaScript "won't be considered valid AMP," and thus would be ineligible for the placement benefits afforded to AMP pages in Google results. AMP's governance is not similar to HTML's. Changes to HTML require consensus between mutually competing browsers, while AMP is a single-vendor land-grab. That consolidation of power threatens to return us to the dark ages of Microsoft's sole dominance of the de facto Web.
- SquareWheel 10y ago
  Thanks for the link to the bug. I wasn't aware of that; I'd assumed the <link> tag was actually functional. I'll concede that point. Locking you in to use their js copy, even if it's faster, is less open than trusting the real HTML.

callahad 10y ago

That's how it should work, but now how it actually works. From https://github.com/ampproject/amphtml/issues/534#issuecomment-273273590 https://github.com/ampproject/amphtml/issues/534#issuecommen...: > "AMP is an evergreen JavaScript library. We will not allow users to lock themselves into a particular release." Which completely precludes using SRI. Further, pages serving their own copy of the JavaScript "won't be considered valid AMP," and thus would be ineligible for the placement benefits afforded to AMP pages in Google results. AMP's governance is not similar to HTML's. Changes to HTML require consensus between mutually competing browsers, while AMP is a single-vendor land-grab. That consolidation of power threatens to return us to the dark ages of Microsoft's sole dominance of the de facto Web.

SquareWheel 10y ago
Thanks for the link to the bug. I wasn't aware of that; I'd assumed the <link> tag was actually functional. I'll concede that point. Locking you in to use their js copy, even if it's faster, is less open than trusting the real HTML.