Design Review 2021-06-23 20:00 UTC (Americas)

[github-actions]

Time: 20:00 UTC (add to Google Calendar)
Location: Video conference via Google Meet

The AMP community holds weekly engineering design reviews. We encourage everyone in the community to participate in these design reviews.

If you are interested in bringing your design to design review, read the design review documentation and add a link to your design doc or issue by the Monday before your design review.

When attending a design review please read through the designs before the design review starts. This allows us to spend more time on discussion of the design.

We rotate our design review between times that work better for different parts of the world as described in our design review documentation, but you are welcome to attend any design review. If you cannot make any of the design reviews but have a design to discuss please let mrjoro@ know on Slack and we will find a time that works for you.

[twifkak]

I would like to discuss a recommendation to put AMP caches on the public suffix list along with the experimental mechanics for this on the Google AMP Cache. Summary from the doc:

Getting an AMP cache on the PSL leads to a TON of changes in how browsers and other web clients interpret them. It mostly falls into these categories:

• Desired restrictions on usage (e.g. cookies, document.domain) as an added layer of defense against restrictions enforced by AMP validator and AMP runtime.
• Desired site isolation (e.g. increased difficulty of side channel attack).
• Performance regressions due to the increased site isolation.
• Desired new capabilities (e.g. private click measurement API in Safari, as well as the upcoming conversion measurement and first-party sets APIs in Chrome).

I propose an experiment to test whether the performance regressions are significant or negligible, and a couple other canaries to guard against unexpected breakages.

[micajuine-ho]

Hi, I'd like to discuss we can use iOS 15's GeoHash Client Header to support amp-geo for Safari users: #34942

[caroqliu]

Hello, I would like to get feedback on #34969, specifically on:

• API changes
• forceChangeHeight -> attemptChangeHeight

[samouri]

I'd like to discuss #34951, an I2D for removing the #development=2 feature.

[twifkak]

Notes on the PSL experiment on Google:

1. Concern that that entries are cached at the first serving tier and not sufficiently at the second tier. The experiment adds the query param to the URL but doesn't remove it until the second tier, so it's subject to confounds from the lower first-tier cache hit rate in the experiment arm. As a post meeting follow-up, I forgot to mention that we'll disable first-tier caching for both experiment and control (via X-Google-Cache-Control). This isn't perfect, either: it overemphasizes the importance of the browser cache on performance since non-browser-cached requests will be slower in both arms. But it seems like a tighter bound.
2. Idea to use a different domain (e.g. gstatic.com) to emulate the network isolation effect. This is a good idea, if we can use subdomains to additional emulate the cache partitioning too. I'll look into it.
3. Idea to simplify the experiment by leaving URLs alone and disabling browser caching in the experiment arm via Cache-Control (and I guess an X-Google-Cache-Control override for the first serving tier). This would be simpler, and possibly subject to fewer confounds, but I'd guess the remaining confound is bigger (not being able to cache JS at all). This would be a good conservative upper bound for the perf cost, but given my post-meeting answer to (1), I think we can get a tighter bound with the existing plan.

Please reach out if you have more thoughts.