AMP users and publishers have told us that they prefer that the original domain names be used anywhere their AMP pages are displayed.
Earlier this year, we demonstrated a technology named Signed HTTP Exchanges that supports transforming cached AMP URLs on any AMP Cache. Google Chrome has since started an origin trial for Signed Exchanges in Chrome 71. Today Google Search is opening up a developer preview of this technology that any publisher can try out for themselves.
Signed Exchanges, used by an AMP Cache, have benefits for users and publishers, beyond the visual experience of the URL bar. Signed Exchanges also:
- Provide a guarantee, using cryptographic signatures, that the content is exactly what the publisher intended to show the user.
- Allow the browser to treat a document as belonging to the publisher’s Origin. This allows a publisher to use first party cookies to customize content, execute service workers, and measure analytics.
Signed Exchanges are part of a wider web proposal named Web Packaging. The Web Packaging specifications, first proposed in 2015 as a W3C draft are evolving over time with feedback from members of standards bodies, other browser vendors, security experts, and publishers and web developers.
Steps to try a Google Search demonstration
- Signed Exchanges are currently only enabled in Chrome version 71 or greater. At the time of writing, this requires installing from the Chrome Beta channel but it will soon be released to all Chrome channels.
- If you are not using a mobile device such as a smartphone or a tablet, enable mobile emulation on your browser. AMP pages are only displayed to mobile devices. Next, visit https://g.co/webpackagedemo.
- This will display a search box. From there, enter a query such as [learn amp by example] and click on “Learn AMP by Example” for the ampbyexample.com home page. There are only a small number of publishers that have implemented this feature so far, so you may want to try this specific query. If you’ve completed these steps correctly, you will see “https://ampbyexample.com” displayed in the browser’s URL bar.
That’s it! The AMP Cache has preloaded the AMP document and Chrome has cryptographically verified that the AMP document was never modified from what the publisher intended, thus enabling the publisher’s URL to be the one that populates the browser address bar.
Under the hood
Prefetching
The moment a Google Search returns an AMP result, the Search results page instructs the browser to fetch the AMP document, “prefetching” it by the device in the background.
When a user clicks on that result, the AMP document can be displayed instantly. This works in part because the document clicked was already fetched and partially loaded.
Heavy resources like images and videos haven’t all been fetched in advance, but the AMP JavaScript libraries make sure to reserve space on the document for those and optimizes the order of loading them. This saves bandwidth if the user doesn’t end up clicking. It also protects the user’s privacy.
An important privacy principle is that until the user clicks on a document, third parties should not be able to determine that the user is interested in it. If preload caused a browser to make network requests to servers other than Google’s, then some of the intent of user queries would leak to sites the user never even clicked on.
To achieve this, neither the document nor any resources fetched before loading the document, can be fetched from third parties. Only once the user has signaled intent to load the document by tapping it do those resources get fetched. We call this mechanism “Privacy Preserving Prefetching” and it provides a buffer between the user and the publisher until the user has chosen which document to visit.
In order to preserve privacy while still prefetching documents, the referrer, Google Search in this case, must load the document from a Google server, the Google AMP Cache.
Signed Exchanges
We would like to achieve the Privacy Preserving Prefetching while simultaneously maintaining the URL and Origin model of AMP documents. We are achieving this using a new collection of browser technologies being drafted under standards bodies such as the W3C and IETF, called “Signed Exchanges”.
A Signed Exchange is an HTTP Request / Response pair, cryptographically signed using a publisher’s own Certificate Private Key. In other words, Signed Exchanges provide digital proof to a browser that the document delivered by an AMP Cache has not been modified from what the publisher intended.
When a browser sees a Signed Exchange and can validate the signature, the browser can display the publisher’s URL, regardless of where the file was delivered from.
AMP Packager
To help publishers build Signed Exchanges, the AMP team has built a tool that can be run by publishers to package and serve Signed Exchanges. The tool is called the AMP Packager.
The AMP Packager runs on publisher’s own infrastructure as a web server backend. It acts like a proxy, accepting an HTTP request for an AMP Web Package, forwarding that request to the publisher’s own backend, and then transforming it into a Signed Exchange.
In addition to packaging the document, the AMP Packager also applies transformations to the document that optimize the page for serving on an AMP Cache. These transformations modify the document itself, without changing the way it looks to users. However, publishers should be able to inspect the code that makes these transformations, so the AMP Packager code, including the transformations applied, is open source.
Developer Preview
Developers who want to opt-in to this developer preview should be first aware that the specification is still changing, and this is an implementation of a snapshot of it.
Once deployed, allow a few days for the Google Search crawler to revisit your site, after which you should be able to try the experience by using the Google Search Demo instructions above.
Option A: Run the AMP Packager tool
The AMP Project has provided the AMP Packager, an open source tool, with detailed instructions on how to run it on your own infrastructure.
During these steps, you will need to generate a new certificate with the CanSignHttpExchanges extension from your Certificate Authority. At the time of writing, the only Certificate Authority that has built a Signed Exchange certificate request flow is DigiCert, with detailed instructions that can be found at Digicert CanSignHTTPExchanges.
Option B: Use a Signed Exchange–Enabled CDN
If you use a CDN provider, ask them if they can provide AMP Signed Exchanges.
At the time of writing, Cloudflare has announced an experimental Cloudflare Worker application implementation of Signed Exchanges as a service to its customers. See this Cloudflare blog post about Web Packaging for more information on how to enable Signed Exchanges on Cloudflare. Once deployed, allow a few days for the Google Search crawler to revisit your site, after which you should be able to try the experience by using the Google Search Demo instructions above.
We’d love to hear from you
We would love to hear your feedback on Signed Exchanges in AMP. You can join the spec discussion, report a chrome bug, report an AMP Packager bug, or general AMP feedback. Your feedback will greatly help us shape the future of AMP and the web.
Posted by Greg Grothaus, Software Engineer, AMP at Google