AMP and the Sandbox Policy

A few weeks ago, I imagined how a Life After AMP could look like, and discussed how AMP isn’t a broad solution for all types of websites yet, plus offered my thoughts on Tim Kadlec’s and Yoav Weiss’ proposal for a Content Performance Policy. Most of all, I pondered whether we might need a standard that’s more generic than the proposed CPP, something like User Experience Interventions.

Shortly afterwards, a group of interested folks, including Tim, Yoav, Ilya Grigorik and myself, met in San Francisco to discuss the next iteration of the proposed spec. I’m now happy to announce that we’re a tiny step (Ilya just posted the proposal to the WICG) closer to a new standard that we now simply call Sandbox Policy.

What the Sandbox Policy is

The Sandbox policy extends the proposed sandboxing capabilities of the HTML spec. In short, it aims to:

1. Allow the policy to be applied to the top-level document with granular opt-in
2. Allow the top-level policy set in (1) to propagate to subframes
3. Allow the policy to run in report-only and enforce+report modes
4. Extend existing sandbox flags with additional restrictions:
4.1. no-sync-script
4.2 no-sync-xhr
4.3 no-docwrite

The Sandbox Policy is inspired by AMP and shares certain concepts and goals. By having a browser-enforced mechanism of “self-control”, i.e. the ability to modify or disable certain web platform capabilities, it enables the following two scenarios:

• Developers can lock down their application against regressions caused by own and third party resources; it enables violation auditing and reporting against specified standards.
• Third parties can validate enforced policies and use them as signals about runtime/UX/performance characteristics of the content.

What the Sandbox Policy is not

The Sandbox Policy doesn’t replace AMP. AMP uses a few fairly aggressive optimization techniques that are targeted at static content delivery (e.g. static layout), techniques that a generic standard could hardly ever replace.

AMP itself would, however, be likely among the first happy consumers of the new Sandbox Policy, as it would allow to enforce certain policies further, like not allowing document.write anywhere: By propagating them to all iframes and their iframes (something AMP technically can’t pull off today).

For sites and web apps that don’t or can’t use AMP, the Sandbox Policy offers a subset of techniques that AMP uses and are generic enough to be used everywhere.

Comment, collaborate and share

This proposal is just that — a proposal! In order to make it a spec that’s implemented by browsers, you need to chime in. Whether you see issues, have further ideas or simply want to state that you’d love to use it in your sites, we need your support to make it a reality.

And finally, huge thanks go out to Tim and Yoav, who got the ball rolling with their CPP, and Ilya Grigorik, who took our messy thoughts and tidied them up in a beautiful spec proposal.

Let’s do this!