Weekly Platform News: Feature Policy, Signed Exchanges, iOS browsers
Feature Policy in Chrome
Andrew Betts: Websites can use the HTTP
Feature-Policy response header to prevent third parties from secretly using powerful features such as geolocation, and to disable certain bad practices (e.g.
This allows good practices to be more easily rewarded. … Search results could be badged with some approving “fast” logomark or (more controversially perhaps) get a higher result ranking if they disallow themselves certain policy-controlled behaviors.
Feature Policy is an emerging technology. See featurepolicy.info for more information about individual policies and their level of support in browsers.
Signed exchanges on Google Search
The mobile version of Google Search includes AMP results on search results pages. When the user taps on an AMP result, the AMP page loads from Google’s domain (
google.com) and is displayed in the AMP Viewer.
Google Search now supports an alternative: If a website signs its AMP pages, and the visitor uses Chrome for Android, then tapping on an AMP result instead loads the signed version of the AMP page from Google’s servers, but to the user it appears as if they have navigated to the website normally.
The technology that enables this is called Signed HTTP Exchanges (SXG). See the announcement on Google Webmaster Central Blog for more details. The specification describes the following use case:
In order to speed up loading but still maintain control over its content, an HTML page in a particular origin “O.com” could tell clients to load its sub-resources from an intermediate content distributor that’s not authoritative, but require that those resources be signed by “O.com” so that the distributor couldn’t modify the resources.
Websites can add support for signed exchanges by running AMP Packager on the server side. Cloudflare has launched a free feature called “AMP Real URL” that fully automates the signing process for AMP pages served from its CDN.
Alternative iOS browsers
Henrik Joreteg: On iOS, several important APIs are limited to Safari and are not available in any of the alternative iOS browsers. These include service workers, web payments, and camera access.
Chrome on iOS is such a pain. A surprising number of people seem to use it and no one realizes it’s not actually Chrome but just a crippled webkit webview missing major features:
1. No Service Worker
2. Can’t print or save as PDF
3. No support for GetUserMedia
Why is this OK?!
— Henrik Joreteg (@HenrikJoreteg) March 30, 2019
Chrome for iOS supports web payments via a custom implementation. I’ve created a browser support table on HTML5test that highlights the differences between some of the popular iOS browsers.