AMP

Cookie classification on AMP

Web Standards

Posted by Katharina Familia Almonte, Global Product Lead at Google on the AMP Project

Last year, Chrome announced its plans to introduce a cookie classification scheme as part of its ongoing effort to improve privacy and security across the web, which is expected to take effect with Chrome 80 in February 2020. Mozilla has affirmed their support of the new cookie classification model with their intent to implement the SameSite=None; Secure requirements for cross-site cookies in Firefox. Microsoft has announced plans to begin implementing the model starting as an experiment as soon as Microsoft Edge 80.

The AMP team is committed to protecting user privacy and this blogpost will explain how you can support greater transparency and user choice with the upcoming browser changes, while also maintaining a good user experience with AMP. With Chrome 80 expected to launch in February, this blogpost will focus on Chrome’s changes specifically.

Chrome’s new cookie settings explained

Chrome’s new secure-by-default model assumes that all cookies should be protected from external access unless otherwise specified. Developers must use a new cookie setting, SameSite=None, to designate cookies for cross-site access, and an additional Secure attribute so cross-site cookies can only be accessed over HTTPS connections. Chrome will treat cookies that have no declared SameSite value as SameSite=Lax cookies. Only cookies with the SameSite=None; Secure setting will be available for external access, provided they are being accessed from secure connections. For more detail on the new model, read this developer blog post.

Who’s affected

If your site needs to access your own first party cookies on AMP pages rendered in the AMP Cache, we recommend assessing carefully whether the upcoming browser changes will impact your user experience. This could be the case, for instance, when users transition from the AMP cache to the origin domain and a paywall, login state, measurement or shopping cart functionality relies on first party cookie access. There are two different solutions you could employ, but which one is best for your site will depend on your specific use cases and can change over time.  

Designating cookies for cross-site access

One solution for AMP publishers affected by Chrome’s cookie classification changes, is to set your first party cookies on AMP pages to SameSite=None; Secure. This will designate the first party cookies  for cross-site access and avoid disruptions in user experience:

Set-Cookie: widget_session=abc123; SameSite=None; Secure

The benefit of this approach is that it is the easier one to implement, but if browsers proceed to offer users fine-grained controls to manage cookies accessed by a single site separately from cookies accessed across multiple sites, there is a higher risk that users will clear your first party cookies on cached AMP pages since they will be marked for cross-site access.

Signed Exchange offers help

Alternatively, publishers can use Signed Exchange to achieve a state where first party cookies are treated as such on AMP pages rendered in the AMP Cache. Signed Exchange is an emerging technology that can be used to attribute the page’s URL to the original publisher domain, even when the page is delivered via the AMP cache with all of the loading speed benefits it provides (see blog post and guide). The benefit of Signed Exchange here is that when browsers start preventing cookies from external access unless they are specified otherwise, Signed Exchange will ensure that your first party cookies don’t require designation on pages rendered in the AMP Cache. But Signed Exchange does not currently address all use cases as it is not supported in the Top stories carousel at the time of writing.

Summary

In summary, Chrome is planning to introduce its new SameSite=None; Secure cookie settings in February. To ensure an optimal user experience on pages in the AMP cache that need to access first party cookies, we recommend publishers designate cookies for cross-site access via these new settings or implement Signed Exchange. We hope this blog post helps you maintain a good user experience while also supporting the path to greater privacy controls for users, as browsers start adopting the new cookie classification model. For more details on how to use and test Chrome’s SameSite cookies check out the guide on web.dev and the tips in the Chromium SameSite Updates.

Leave a Reply

Your email address will not be published. Required fields are marked *