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.

CCPA support in AMP

Web Standards

Posted by Jeffrey Jose, Product Manager at Google on the AMP Project

The California Consumer Privacy Act (CCPA) is a new data privacy law that establishes various rights for California state residents. The law applies to companies that do business in California and meet one of several criteria related to revenue, data processing, and other factors. 

Updates to the AMP consent framework

Based on the feedback we heard from publishers, we’ve updated the AMP consent framework to obtain the consent publishers might deem necessary for CCPA compliance. With these new updates, publishers can include multiple consent prompts and trigger the right prompt based on the location of the user.

Consent across multiple surfaces

Publishers who wish to keep user consent in sync between multiple surfaces can store the user’s consent on the server-side and expose the information to <amp-consent> via the checkConsentHref attribute. You can configure AMP to check your endpoint first and the response determines whether a user-consent prompt is displayed or not. Additionally, the previously obtained user consent can be passed from the server to the ads and analytics vendors configured on the page.

Support in AMP Stories

For AMP Stories, publishers can create links to their CCPA opt-out page within a story to collect user consent. 

We’ve also updated our reference docs and amp.dev with sample codes to illustrate sample scenarios.

Looking ahead

To make development easier, we plan to extend <amp-geo> in the future by providing US state level detections of users. As always, we invite you to submit new ideas by filing an issue. If you’re a vendor who wants to customize how your AMP extensions behave based on user controls, please get started by following our contribution guidelines.

Innovation in navigation on the web platform

Web Standards

In this third post in our series on contributing back lessons learned from AMP to the whole web, we’ll dive into the topic of innovating on the concept of navigation for web content. Additionally, we’re taking a look at how new primitives in the web platform are helping to make AMP simpler and “less of a thing”.

If you haven’t read the first or second post, we’d suggest to hop over there before reading this.

For as long as the web has existed, navigation meant that when the user clicked a link, the browser would paint white, and eventually it would paint the new page and update the URL bar. While this is an amazing model, more sophisticated interaction patterns have emerged on mobile. So far it has only been possible to implement these on the web using complicated “single-page app” patterns that use iframes for third-party content. Iframes are a great asset to the web platform. They enable composability, one of the SLICE special powers of the web. Unfortunately, the composability enabled by iframes inherently results in restrained user experiences. An iframe is like a fixed window: it lets you see into another world, but since it can’t be opened it doesn’t let you cross to the other side. The Chrome team took notice of an early exploration called iframe promotion which was designed to give iframes the ability to be navigated to. After a few rounds of discussion to build on this idea, the Chrome team identified a way to avoid the architectural complexity of a solution based on iframes and proposed a similar approach called Portals which allows for unfettered composability.

https://blog.amp.dev/wp-content/uploads/2019/06/portals_h264.mp4
Portals demo

We’ve seen a lot of interest about Portals from the web community, if only because they’ll allow for applications with the simplicity and robustness of having single pages per URL with the interaction fidelity of single-page apps.

With Portals we hope to be able to implement experiences like Google’s Top Stories carousel without having to rely on application layer solutions like AMP. Beyond that there are a lot of exciting use cases for Portals such as payment or single-sign-on solutions that are visually integrated into a website, but when activated show the user the true origin they are interacting with such as their payment provider.

Simplifying AMP

Putting all the things we introduced in this and previous posts together, one cool side-effect of the web platform getting more powerful is that we are getting ready to make large chunk of AMP literally go away and be replaced by simple platform primitives.

One example that is within arm’s reach is the removal of amp-img as a web component. With lazy loading, priority hints, and intrinsic sizing being implemented in browsers, it is possible to see a future in which there is no longer a need for the custom component–and while it’ll stick around for backward compatibility, it makes us incredibly happy to make AMP less complicated and instead focus even more on providing high level components in an easy to use framework, as opposed to the platform magic on top to make it all work.

Summary

A lot of progress has been made over the last year in advancing web standards along various dimensions. Above we highlighted the areas that the AMP team together with our friends from Chrome and Igalia have invested the most time on, but we also want to recognize that lots of other folks in the entire web community are doing awesome work on web standards which are helping make the web better every day. The AMP team is learning a lot from the web community and is currently most excited about isInputPending, display locking, and Animation Worklet.
Concrete proposals for privacy-preserving instant loading, innovative navigation, performance assessment, and development guardrails are now on the table and in varying stages of implementation. We hope that these projects are a step in the right direction to help all web developers create more delightful experiences regardless of implementation choices. We are eager to hear your feedback and can’t wait for the progress that will be made in the next year!

Posted by Malte Ubl, Member of the AMP Technical Steering Committee, Software Engineer at Google 

Privacy-preserving instant loading for all web content

Web Standards

In this second post in our series on contributing back lessons learned from AMP to the whole web, we’ll dive into the topic of instant loading. If you haven’t read yesterday’s post, we’d suggest to hop over there before reading this.

So what is privacy-preserving instant loading? It can be summarized as:

  • Instant loading means link navigations work instantly without any perceivable wait time.
  • In general that means they work without going to the network, because the network may be slow.
  • But not going to the network when the user clicks means to request the page some time before the user really initiated the navigation.
  • This may leak sensitive information to the page, such as that the user is interested in it, without user consent.
  • Privacy-preserving instant loading is instant loading where this information leak does not happen.

For more on this topic, see our post on privacy and user choice in AMP’s software architecture.

Below we describe a set of changes that combined enable content sharing websites, social media platforms, and search engines, such as Google Search, to provide privacy-preserving instant loading for web content that is not based on AMP.

After an extensive process where both AMP and Chrome teams identified and assessed potential solutions, encouraged by W3C TAG’s recommendation, Chrome’s web platform team eventually convinced us to explore the emerging Web Packaging standard and its component Signed Exchanges (SXG), and further invest in its standardization and implementation. SXGs help with privacy-preserving instant loading by allowing the referring site (such as the search engine) to load a resource from a trusted server without leaking any additional information to a third-party. Then, once the user navigated to the SXG, everything behaves just like any other web navigation (except for the faster load).

SXG support has recently landed in the stable version of Chrome, but is not yet available in non-Chromium based browsers. SXGs are a big step for the web platform: They disentangle attribution (who created a piece of content) from initial delivery (how is the initial view of the content delivered to the user), and guarantee content integrity (the content distributor cannot change it). While this creates exciting new opportunities like a more decentralized web, it also creates new security challenges that need to be worked through diligently.

On top of SXG support, we’ve worked with Igalia on making prefetching available across browsers. While <link rel=prefetch> had been specified for a while and widely used, it wasn’t available in browsers like Safari because of incompatibilities with double-key caches. The Chrome team proposed and discussed a change that makes prefetching compatible with double-keying, and Igalia’s patch just landed in WebKit.

Additionally, the Chrome team worked with the community on clarifying the spec for nested prefetches, i.e. when a prefetched resource schedules additional sub-resources to be downloaded. A Chromium contributor subsequently added support to preload for image srcsets after discussion with other w3c members and our partners at Igalia, who help us with implementing web features in WebKit, have recently landed similar patches in WebKit.

Summary

This was part 2 in our series of contributing lessons learned from AMP to the whole web. We’ve now discussed how to measure performance at scale and how to enable instant loading for web content. In the next post in the series we’ll talk about ideas for how to innovate on the concept of navigation.

Posted by Malte Ubl, Member of the AMP Technical Steering Committee, Software Engineer at Google 

A year into contributing back lessons learned from AMP to the whole web

Web Standards

In March of 2018 we wrote about our effort to contribute back the things we learned from AMP for the benefit of all web developers by addressing gaps in the web platform. In this work we’ve collaborated with the Google Chrome team, Igalia, who is helping us with implementation work in WebKit, and, of course, the wider web standards community. We’ve also learned a lot from the community and have seen a lot of exciting work that we can’t wait to apply. This is an update on how that effort is going.

Our work has focused on bringing the benefits that AMP implemented on the application layer to the whole web platform (AMP or otherwise):

  • Measuring performance and user experience: Make it possible to objectively measure high load performance and certain UX properties, such as a stable loading experience without content that is shifting around as it loads.
  • Privacy-preserving instant loading: Allow the preloading of web content, before a user clicks, without leaking the user’s interest in the page to the page author until the user navigates.
  • Innovation in navigation: Navigation from one web page to another through means other than the traditional click. E.g. by swiping through a carousel or scrolling from one article to another one.
  • Guardrails: Provide a mechanism for development teams to avoid the use of certain legacy features of the web platform that are harmful to UX. Give development teams  similar control over the behavior of third-party code.

We’ve made significant progress distilling our original wide-ranging ideas and worked with the web community to turn them into concrete standard proposals. This is a lot to go through, so we’ll split things up into a series of posts starting with the topics Measuring performance and user experience and Guardrails today.

Measuring performance and user experience

The AMP team often gets the question: Why don’t you just measure whether a page is fast instead of relying on AMP? And we agree, that is a good question.

One of the big changes in the web space since AMP was created is that there are now tools like the Chrome User Experience Report, which do, in theory, provide a way to get performance data for most sites on the web. Looking at this further we realized, however, that the existing metrics are insufficient to really make statements about the desirable user experience properties of web pages.

Legacy metrics like onload aren’t great proxies for user-perceived performance. Pages can both appear loaded long before onload fires and can appear NOT to have loaded long after onload fires.

One modern metric, First Contentful Paint (FCP), is the only currently available candidate metric for measuring perceived performance at scale. Unfortunately, while good user experiences always have a good FCP, having a good FCP is insufficient to really know whether a page is fast. FCP should probably have been called First Not-Completely-Trivial Paint because it is clear that users would in many instances not consider a page to be sufficiently rendered at the time of its FCP. For example, a loading indicator would trigger FCP, but the user wouldn’t be happy at this stage.

For these reasons we invested in defining additional metrics that would paint a more holistic image of user perceived performance. The two metrics currently under discussion are Largest Contentful Paint (LCP, name subject to change), which fires when the largest element of text or image on a page has painted, and Layout Stability, which is an indicator for how stable the layout is during page load. We’re hoping that these metrics, together with First Input Delay, which is further along in standardization, would allow one to say with reasonable confidence whether a page is fast and well-behaved from a user point of view.

An example of a page doing badly on the layout stability metric.

Guardrails

AMP introduced the AMP validator to ensure that documents complied with a range of best practices and to give helpful error messages when they didn’t. Based on earlier work by Tim Kadlec and Yoav Weiss on the Content Performance Policy idea, the notion of Feature Policies was developed through discussions with the web community. They provide both a way to turn off harmful legacy features, such as synchronous XHR, and to report violations of best practices, such as loading images that are much bigger than necessary, to the development team of a website.

A whole range of Feature Policies are in the works now covering many aspects of web development. One interesting aspect for Feature Policies that while wide browser support is desirable for enforcement, for reporting only mode, where you get notified about issues with your website, partial browser support is often sufficient to solve the identified issues for users of all web browsers.

Summary

This ends part 1 of our series of posts on contributing back lessons learned from AMP to the whole web. Thanks to the whole web community for the amazing help in getting these standards proposal on track and the great feedback to make them much better than we could have ourselves!

Next up in this series of posts is Privacy-preserving instant loading and Innovation in navigation. They’ll be posted on this blog in the coming days.

Posted by Malte Ubl, Member of the AMP Technical Steering Committee, Software Engineer at Google