Intent to Implement: Feature Policy control over sandbox features

[Ian Clelland]

Contact emails

ekar...@chromium.org, icle...@chromium.org

Explainer

Original Chromium doc: https://docs.google.com/document/d/1KsCFmugEAZf1LT_C3ZCj8FfkkljZV3D3EoMenX7yQto/edit

Updated explainer: https://github.com/WICG/feature-policy/blob/master/sandbox.md

Summary

At a high level, there are two major changes:

1. Implement nine sandbox features in terms of feature policy -- this is largely an internal architectural change, and should be backwards compatible with existing content, since the inheritance mechanisms of sandbox and feature policy are  compatible, as are the timings for when changes in the parent take effect in the child.

2. Add feature-policy-features for each of the sandbox features, so that the 'allow' attribute can *also* be used to control the sandbox features -- since many or most of them are useful features in their own right, and could be used outside of sandboxing.

The sandbox attribute itself will remain, and will function as it does today, to preserve backwards compatibility.

The features which will be added to feature policy are:

• "forms"

• "modals"

• "orientation-lock"

• "plugins"

• "pointer-lock"

• "popups"

• "presentation"

• "scripts"

• "top-navigation"

Motivation

Iframe sandboxing currently controls several features which would be very useful even *without* sandboxing. The ability to restrict the use of plugins, or navigation of parent documents, or opening popups / modal dialogs, are all currently coupled with sandboxing. The intent of this change is to decouple those from sandbox and make them independent policy-controlled features, so that they can be used everywhere, and controlled in a consistent manner as the rest of the feature policy features.

Risks

Interoperability and Compatibility

The biggest interoperability risk with this change is that sites use this mechanism to try to disable features without being aware of whether or not it is actually going to work. (Simply assuming that it works without being aware of differences between browsers)

To this end, we are also working on providing an interface for sites to determine in script what features are available for use in feature policy. This could be used for feature detection

It is also possible that sites use this feature to specify policies that will work one way in Chrome, and another way in a browser which does not support feature policy -- disabling features in a sandboxed frame but re-enabling them with feature policy -- in that case, if we remove this feature, then Chrome will start behaving as the other browsers already do.

Edge: No signals

Firefox: No signals

Safari: No signals

Web developers: No signals

No signals yet, but we intend to actively solicit them.

Ergonomics

Are there any other platform APIs this feature will frequently be used in tandem with?

This can be used to control the availability of other APIs, but is not really used in tandem with them. It is likely to be used with the Feature Policy JavaScript API, which is currently in an origin trial (M69-M71) to expose to developers what features are actually available to control.

Could the default usage of this API make it hard for Chrome to maintain good performance (i.e. synchronous return, must run on a certain thread, guaranteed return timing)?

This shouldn't have any negative performance constraints.

Activation

Developers should be able to take advantage of this immediately, to restrict the capabilities of their own sites, and the sites they embed.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5232684104155136

Requesting approval to ship?

No

[a...@google.com]

On Tuesday, July 24, 2018 at 7:40:18 PM UTC+2, Ian Clelland wrote:

Contact emails

ekar...@chromium.org, icle...@chromium.org

Explainer

Original Chromium doc: https://docs.google.com/document/d/1KsCFmugEAZf1LT_C3ZCj8FfkkljZV3D3EoMenX7yQto/edit

Updated explainer: https://github.com/WICG/feature-policy/blob/master/sandbox.md

Summary

At a high level, there are two major changes:

1. Implement nine sandbox features in terms of feature policy -- this is largely an internal architectural change, and should be backwards compatible with existing content, since the inheritance mechanisms of sandbox and feature policy are  compatible, as are the timings for when changes in the parent take effect in the child.

2. Add feature-policy-features for each of the sandbox features, so that the 'allow' attribute can *also* be used to control the sandbox features -- since many or most of them are useful features in their own right, and could be used outside of sandboxing.

Since the `allow' attribute on an iframe takes precedence over the `sandbox' attribute, does this mean that it would be semantically different from setting a Feature-Policy as a header on the response serving the contents of the frame? I.e. when loading a sandbox iframe it would be necessary to treat the Feature-Policy response header differently from the `allow' attribute on the iframe, or otherwise the document could lift sandbox restrictions on itself by setting a permissive policy via the FP header. (This is probably obvious, I just wanted to check that this is the intended behavior).

 

The sandbox attribute itself will remain, and will function as it does today, to preserve backwards compatibility.

Part of the model of sandbox frames is that the restrictions propagate across navigations and to newly opened windows; I assume this is not the case for Feature Policy, right? A small concern here is that if developers start relying on FP to set sandbox-like restrictions, some of them could be subverted; for example if I load a cross-origin frame and block its scripting capabilities with FP, it could potentially open a new window which will be able to execute scripts and arbitrarily modify the locked-down frame via same-origin DOM interactions. So I'm a little unclear about the overall security model of this...

[Joe Medley]

Ian,

Do you have a tracking bug for this? (If 'tracking' is the right term. I forgot what we're calling them these days.)

Joe

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a2674d2b-a2c8-436b-8850-c3b6cb0a770e%40chromium.org.

[Ian Clelland]

Sorry for the lengthy delay; just back from vacation and catching up.

On Thu, Jul 26, 2018 at 3:46 PM aaj via blink-dev <blin...@chromium.org> wrote:

On Tuesday, July 24, 2018 at 7:40:18 PM UTC+2, Ian Clelland wrote:

Contact emails

ekar...@chromium.org, icle...@chromium.org

Explainer

Original Chromium doc: https://docs.google.com/document/d/1KsCFmugEAZf1LT_C3ZCj8FfkkljZV3D3EoMenX7yQto/edit

Updated explainer: https://github.com/WICG/feature-policy/blob/master/sandbox.md

Summary

At a high level, there are two major changes:

1. Implement nine sandbox features in terms of feature policy -- this is largely an internal architectural change, and should be backwards compatible with existing content, since the inheritance mechanisms of sandbox and feature policy are  compatible, as are the timings for when changes in the parent take effect in the child.

2. Add feature-policy-features for each of the sandbox features, so that the 'allow' attribute can *also* be used to control the sandbox features -- since many or most of them are useful features in their own right, and could be used outside of sandboxing.

Since the `allow' attribute on an iframe takes precedence over the `sandbox' attribute, does this mean that it would be semantically different from setting a Feature-Policy as a header on the response serving the contents of the frame? I.e. when loading a sandbox iframe it would be necessary to treat the Feature-Policy response header differently from the `allow' attribute on the iframe, or otherwise the document could lift sandbox restrictions on itself by setting a permissive policy via the FP header. (This is probably obvious, I just wanted to check that this is the intended behavior).

Yes, but this isn't new behaviour; the Feature-Policy response header is always treated differently than the allow attribute in the embedding document; the response header can only be used to disallow use of a feature in the current document which would otherwise be allowed, and to declare which of its own child documents to allow the feature in. It can't override the embedding document's decision to turn a feature off.

 

 

The sandbox attribute itself will remain, and will function as it does today, to preserve backwards compatibility.

Part of the model of sandbox frames is that the restrictions propagate across navigations and to newly opened windows; I assume this is not the case for Feature Policy, right?

When set by the allow attribute, feature policy restrictions apply across navigations in exactly the same way as sandbox restrictions currently do -- although they are more flexible:

<iframe allow="forms 'none'" src="..."></iframe>

will disable the 'forms' feature in the contents of that iframe, and all of its descendants, no matter where the frame is navigated to. There will never be an origin that matches the 'none' keyword. This is essentially the sandbox behaviour for frames. Feature policy also allows you to lift the restrictions partially, with syntax like:

<iframe allow="forms https://example.com" src="..."></iframe>

This would completely disable the feature, unless the frame was navigated to https://example.com. (Assuming no other restrictions disabled it). The "sandbox" attribute is always going to be equivalent to the first, disabled-everywhere, syntax, though.

When set by the Feature-Policy header, any restrictions will apply to the current document, and will not survive navigation. This is also consistent with sandboxing, when set by the Content-Security-Policy response header.

For windows opened by sandboxed frames (when popups are allowed), we're going to be trying to keep the same mechanisms in place -- respecting the 'allow-popups-to-escape-sandbox' flag, and propagating the feature policy restrictions to new windows unless that is present. Since there may be some subtleties there, we should probably track that in a github issue (to be resolved before I2S)

 

A small concern here is that if developers start relying on FP to set sandbox-like restrictions, some of them could be subverted; for example if I load a cross-origin frame and block its scripting capabilities with FP, it could potentially open a new window which will be able to execute scripts and arbitrarily modify the locked-down frame via same-origin DOM interactions. So I'm a little unclear about the overall security model of this...

Ideally this isn't possible (as I mentioned above, the restrictions should propagate); the bigger concern in the web ecosystem might be that developers rely on FP to set sandbox restrictions which do not apply in all browsers, but that is the case with any FP feature -- and to a lesser extent, any sandbox feature at all, as support for all of the sandbox flags isn't universal.

Ian

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

[Ian Clelland]

Joe,

https://crbug.com/812381 looks like the right one -- I'll make sure that it's assigned.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJUhtG-%3D3ogpSJ4yPTKD8Pu6EC-NFMpmrYgUzwWm%3D1SvOF-jUQ%40mail.gmail.com.

[Joe Medley]

Thanks.

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.