I2I: Opt-in to Specific AMP RTV

[danielrozenberg]

Background

When investigating an issue that was reported to us in the wild, once the issue is reproduced, a natural next step is to use the opt-in cookies to RC and Canary to investigate whether the issue reproduces in different versions of the AMP runtime and under various experiment configs. However, this marks the extent to which an individual can investigate in what versions and configs of AMP the issue exists.

Overview

This I2I proposes the addition of a new version opt-in mode, to allow bisecting reported issues. With the planned future transition to nightly builds, this ability will prove indispensable for release engineers when determining whether to patch or roll back a version when an issue is found.

As Google is responsible for serving the AMP runtime, the implementation details will be mostly up to Google engineers.

Implementation details

Add a new option to opt-in to a specific RTV number in the experiments.html page. The page should provide a list of possible RTV numbers to prevent someone from mistyping a number. These will provide a full (15 digits) RTV. AMP RTV numbers are composed of a 2-digit number that indicates the environment (00 for canary, 01 for prod, 02 for control, 03 for RC, and 10–12 and 20–25 for various experimental builds and their control versions) and a 13-digit number indicating a specific code version (see description of the 13-digit version number)

Selecting an RTV number and clicking the button below it should opt-in the individual to that specific version, with a cookie set to expire after 1 hour. This is because the purpose of this opt-in is to bisect issues, and so the short expiration is meant to avoid a situation where an individual is “stuck” on an old version of AMP for a long period.

Security considerations

Unless protected against, a malicious actor can perform an XSS attack to arbitrarily set this cookie to a broken AMP version with security/privacy bugs. The opt-in mechanism should be designed with this type of attack in mind.

Alternatively, we can restrict the cookie to only allow opting-in to a very narrow set of versions, e.g., a “Monday through Friday cookie”. This can reduce the incentive for such an attack as the opportunity for specifying a bad version is greatly reduced. The downside of this is that it costs us the freedom in terms of debugging abilities, especially when attempting to locate a long-standing issue that was only recently discovered.

Another alternative is to use an OS level proxy to replace any arbitrary calls to https://cdn.ampproject.org/* to chosen RTV-locked equivalents, https://cdn.ampproject.org/rtv/<rtv-number>/*. This is only useful for OSes where such a proxy exists and is easily installable, e.g., this could be difficult in mobile devices. Depending on the proxy software, this also does not necessarily come with an auto-expiration policy which could accidentally lock a developer into one RTV number.

/cc @ampproject/wg-infra