3 ms·

This concern, Google controlled/hosted JS, is independent from Signed Exchanges and specific to AMP. At the same time, the AMP project is actively working to m

This concern, Google controlled/hosted JS, is independent from Signed Exchanges and specific to AMP. At the same time, the AMP project is actively working to move the origin (control/host) of the AMP Javascript to the publisher's own domain, as well as allow a version served on an origin owned by the OpenJS Foundation, rather than Google.

saurik 6y ago
Will this mean that sites will be able to finally lock in a version of AMP? The idea that there is one place right now that is required for all AMP sites that can dynamically update the behavior of all such pages is, in fact, terrifying to me; like, I went into reading this discussion thinking AMP wasn't making anything worse and being super unhappy that anyone even thought to denigrate signed exchanges (as I want those deployed everywhere in order to provide censorship resistant web caching) and then I got convinced by kbenson that this is actually a bit of a dystopia scenario for the web once you involve AMP... I even managed to find an issue about solving this problem with subresource integrity (one you were involved in) that apparently got closed with prejudice (not by you) under an insistence that this javascript injection be an "evergreen" codebase lest somehow everything becomes super insecure, which to me just indicates a fundamental architectural flaw in the security model of AMP :/. https://github.com/ampproject/amphtml/issues/534 https://github.com/ampproject/amphtml/issues/534
- gregable 6y ago
  Yes and No, mostly yes: On publisher origin, the plan-of-record does not involve any validation of the contents of the AMP javascript files. When an AMP Cache (eg: Google) crawls one of these AMP documents, the same is true - the contents of the javascript files will not be relevant to the decision of whether or not the document is considered valid AMP. The files will likely not even be crawled by the Cache. However, when the AMP Cache serves one of these files, it will rewrite them to the latest* version for serving to users. This is necessary since the javascript runs in a somewhat privileged context in search results. https://github.com/ampproject/amphtml/issues/25873 https://github.com/ampproject/amphtml/issues/25873 * There is also a mechanism for publishers to opt-in documents to a "Long-Term Stable" release, rather than the latest evergreen version: https://amp.dev/documentation/guides-and-tutorials/learn/spec/release-schedule/#long-term-stable-lts https://amp.dev/documentation/guides-and-tutorials/learn/spe... Lastly, and there is still some discussion around this, it is likely that Signed Exchanges may be able to load the publisher's own version of the javascript in the future, even in search results. This is because the execution context of the javascript is different for Signed Exchanges.

saurik 6y ago

Will this mean that sites will be able to finally lock in a version of AMP? The idea that there is one place right now that is required for all AMP sites that can dynamically update the behavior of all such pages is, in fact, terrifying to me; like, I went into reading this discussion thinking AMP wasn't making anything worse and being super unhappy that anyone even thought to denigrate signed exchanges (as I want those deployed everywhere in order to provide censorship resistant web caching) and then I got convinced by kbenson that this is actually a bit of a dystopia scenario for the web once you involve AMP... I even managed to find an issue about solving this problem with subresource integrity (one you were involved in) that apparently got closed with prejudice (not by you) under an insistence that this javascript injection be an "evergreen" codebase lest somehow everything becomes super insecure, which to me just indicates a fundamental architectural flaw in the security model of AMP :/. https://github.com/ampproject/amphtml/issues/534 https://github.com/ampproject/amphtml/issues/534

gregable 6y ago
Yes and No, mostly yes: On publisher origin, the plan-of-record does not involve any validation of the contents of the AMP javascript files. When an AMP Cache (eg: Google) crawls one of these AMP documents, the same is true - the contents of the javascript files will not be relevant to the decision of whether or not the document is considered valid AMP. The files will likely not even be crawled by the Cache. However, when the AMP Cache serves one of these files, it will rewrite them to the latest* version for serving to users. This is necessary since the javascript runs in a somewhat privileged context in search results. https://github.com/ampproject/amphtml/issues/25873 https://github.com/ampproject/amphtml/issues/25873 * There is also a mechanism for publishers to opt-in documents to a "Long-Term Stable" release, rather than the latest evergreen version: https://amp.dev/documentation/guides-and-tutorials/learn/spec/release-schedule/#long-term-stable-lts https://amp.dev/documentation/guides-and-tutorials/learn/spe... Lastly, and there is still some discussion around this, it is likely that Signed Exchanges may be able to load the publisher's own version of the javascript in the future, even in search results. This is because the execution context of the javascript is different for Signed Exchanges.