Amphtml: Add URLs for beta and experimental release channels (as was done for LTS)

[westonruter]

This was originally raised in #24731 which allowed (and recommends) adding crossorigin=anonymous to all CDN scripts. This is important for a service worker to be able to cache resources. In fact, @jridgewell actually indicated this should be part of the boilerplate code going forward:

Turns out, crossorigin=anonymous is a requirement for us to receive error reports from the runtime. We should begin the process to make this a mandatory part of the boilerplate (giving people enough time to migrate, of course).

One concern that @choumx raised about this was:

The one issue I can see is that dev channel won't work since cookies won't be sent in anonymous mode.

If crossorigin=anonymous then is standard, then the cookie-based opt-in to beta/experimental channel won't work anymore.

So this brought to mind the new LTS channel which has a dedicated LTS-specific base URL which is distinct from the stable channel. Should there actually be distinct channels for experimental and beta as well to avoid the required dependency on cookies to opt-in? I can imagine this would be useful for dev environments which publishers may want to _always_ pin to experimental, and _always_ pin a QA environment to beta, and then leave the prod environment pinned to stable or lts? For example:

Channel | Runtime URL
---------|-------------
stable | https://cdn.ampproject.org/v0.js
lts | https://cdn.ampproject.org/lts/v0.js
beta ✨ | https://cdn.ampproject.org/beta/v0.js
experimental ✨ | https://cdn.ampproject.org/experimental/v0.js

Additional context here is the WordPress plugin. I'm working on a PR (https://github.com/ampproject/amp-wp/pull/4390) to update to the latest AMP spec, which includes an LTS opt-in as well as adding crossdomain=anonymous to the script and link tags. Currently the LTS opt-in is a boolean. However, it could be an enum including stable, lts, beta, and experimental. This doesn't make sense at the moment because there are only base URLs for stable and lts. But if there were base URLs for the other channels, then it would make sense.

Related:

• https://github.com/ampproject/amphtml/issues/25616
• https://github.com/ampproject/amphtml/issues/25560
• https://github.com/ampproject/amphtml/issues/25578
• https://github.com/ampproject/amphtml/issues/26861

[westonruter]

/cc @ampproject/wg-infra

[nainar]

This is a fair request. @rsimha thoughts?

[danielrozenberg]

I strongly disagree with making this valid AMP - we definitely don't want publishers to pin their website to a beta version. LTS is different because it adds stability, not reduced it.

We can certainly add aliases to specific channels, and have developers use the browser's dev-tools to redirect to those versions (or even develop an extension!)

We should also think about doing /nightly and /experiment-a (-b, -c)

[westonruter]

I strongly disagree with making this _valid_ AMP - we definitely don't want publishers to pin their website to a beta version. LTS is different because it _adds_ stability, not reduced it.

Good point. This pairs well with data-ampdevmode then, so a site can explicitly acknowledge that the scripts are invalid but suppress the validation errors for them.

I think there should be separate URLs for the channels and not depend on an extension, as this will lower the barrier of entry for some users (e.g. QA) to be able to access those channels, and for non-prod environments to consistently use the same release channel for all users.

[rcebulko]

I agree that this definitely should not be valid AMP. As for the alias, don't we already support some version of the opt-in cookie through a URL param? If not, maybe that would make sense? The path-based approach was used for LTS because content security/caching policies can only pin on paths, not on URL params. It might be a cleaner change to allow a URL param that is read in place of the opt-in cookie. WDYT Daniel?

[danielrozenberg]

@westonruter said:

Good point. This pairs well with data-ampdevmode then, so a site can explicitly acknowledge that the scripts are invalid but suppress the validation errors for them.

+1

I think there should be separate URLs for the channels and not depend on an extension, as this will lower the barrier of entry for some users (e.g. QA) to be able to access those channels, and for non-prod environments to consistently use the same release channel for all users.

I was suggesting having an extension as an added thing; the existence of an extension would depend on having these URLs to begin with :)

@rcebulko said:

I agree that this definitely should not be valid AMP. As for the alias, don't we already support some version of the opt-in cookie through a URL param? If not, maybe that would make sense? The path-based approach was used for LTS because content security/caching policies can only pin on paths, not on URL params. It might be a cleaner change to allow a URL param that is read in place of the opt-in cookie. WDYT Daniel?

I prefer this! Something like /v0.js?devmode=beta or /v0.js?optin=beta?

[rcebulko]

If we use optin=$cookieString we can support the same values that experiments.html currently sets, which would make parsing/handling on the backend more uniform

[danielrozenberg]

The cookie string right now for Beta and Experimental is beta and experimental 😅

[danielrozenberg]

Should we discuss this in tomorrow's design review? So far there seems to be only one topic scheduled (and it's mine) and this seems like a noncontroversial quick topic :)

[jridgewell]

I strongly disagree with making this valid AMP - we definitely don't want publishers to pin their website to a beta version. LTS is different because it adds stability, not reduced it.

Agreed.

or even develop an extension!

Please!

The path-based approach was used for LTS because content security/caching policies can only pin on paths, not on URL params.
I prefer this! Something like /v0.js?devmode=beta or /v0.js?optin=beta?

The per directory policy would be nice to configure separately for each mode (mainly targeting stable vs everything else). I would still recommend we use paths, but it's not as hard of a requirement as it was for LTS.

[choumx]

One risk to consider is publishers pushing pages that rely on experimental/insecure features to production. E.g. Chrome's origin trials were designed to avoid this and they do so by disabling the experimental feature if usage exceeds X%.

One way to avoid this is to _not_ support an experimental URL (which probably has limited testing usefulness anyways). Another mitigation is to enforce a non-renewable expiry date on all experiments in canary-config.json.

[danielrozenberg]

I'm not sure I understand what you mean