Intent to Ship: Feature Policy control over document.domain.

[Mike West]

Contact emails mk...@chromium.org Explainer https://github.com/w3c/webappsec-feature-policy/issues/241 Spec https://github.com/whatwg/html/pull/4170 Summary The document-domain policy governs access to document.domain. It is enabled by default, and, if disabled, attempting to set document.domain will throw an error. Link to “Intent to Implement” blink-dev discussion https://groups.google.com/a/chromium.org/d/msg/blink-dev/Ff6Ywg5vnh4/VbDH4X6wBQAJ Risks

Interoperability and Compatibility Browsers that don't support Feature Policy generally, or this feature specifically, won't be able to apply this restriction, but that leaves developers no worse off than they are in the status quo with regard to their ability to limit cross-origin frames. Firefox: In development (https://searchfox.org/mozilla-central/source/dom/html/nsHTMLDocument.cpp#946) Edge: No public signals Safari: No public signals Web developers: No signals Security In order for this mechanism to be useful for site isolation and/or process selection during navigation, we need to ship something like Origin Policy. If that never ships, this feature will be less useful in itself (though will still serve as a helpful partial explanation of `sandbox`).

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests? Yes https://wpt.fyi/results/html/browsers/origin/relaxing-the-same-origin-restriction/document_domain_feature_policy.tentative.sub.html?label=master&product=chrome%5Bexperimental%5D&product=edge&product=firefox%5Bexperimental%5D&product=safari%5Bexperimental%5D&aligned Tracking bug https://crbug.com/904351 Link to entry on the Chrome Platform Status https://www.chromestatus.com/features/5341992867332096

-mike

[Anne van Kesteren]

On Mon, Mar 18, 2019 at 9:21 AM Mike West <mk...@chromium.org> wrote:
> Firefox: In development (https://searchfox.org/mozilla-central/source/dom/html/nsHTMLDocument.cpp#946)

To be clear, as per
https://bugzilla.mozilla.org/show_bug.cgi?id=1531012 and discussed at
https://github.com/w3c/webappsec-feature-policy/issues/282 we're not
shipping Feature Policy and are not entirely comfortable with the
current architecture. It's correct that we've implemented some
aspects, but please don't use that as a signal.

[Mike West]

That's quite fair. On this feature in particular, however, it seemed like there was reasonable agreement with you on the infrastructure change in https://github.com/whatwg/html/pull/4170 and with baku@ on the general idea in side conversations on IRC.

I went back and forth on which label to use here, but since y'all had actually implemented the feature, "In Development" seemed reasonable. Perhaps "mixed public signals" would be more accurate?

-mike

[Anne van Kesteren]

Mozilla is opposed at this point. I have two concerns with this
particular feature, that mostly came to light after the earlier
discussion:

1. I'm no longer convinced that influencing the control flow of
cross-origin contexts is a good idea without the cross-origin context
opting into that. That is, new sandboxing mechanisms should be done in
a way similar to CSP: EE.
2. If we want to offer sites a primitive here for more isolation what
we need is to influence the creation of the agent cluster key as
described at https://github.com/whatwg/html/issues/4361. This needs to
be set when a document from an origin is first navigated to in a
browsing context group.

[Ian Clelland]

On Mon, Mar 18, 2019 at 5:39 AM Anne van Kesteren <ann...@annevk.nl> wrote:

On Mon, Mar 18, 2019 at 10:25 AM Mike West <mk...@chromium.org> wrote:
> On Mon, Mar 18, 2019 at 10:15 AM Anne van Kesteren <ann...@annevk.nl> wrote:
>> To be clear, as per
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1531012 and discussed at
>> https://github.com/w3c/webappsec-feature-policy/issues/282 we're not
>> shipping Feature Policy and are not entirely comfortable with the
>> current architecture. It's correct that we've implemented some
>> aspects, but please don't use that as a signal.
>
> That's quite fair. On this feature in particular, however, it seemed like there was reasonable agreement with you on the infrastructure change in https://github.com/whatwg/html/pull/4170 and with baku@ on the general idea in side conversations on IRC.
>
> I went back and forth on which label to use here, but since y'all had actually implemented the feature, "In Development" seemed reasonable. Perhaps "mixed public signals" would be more accurate?

Mozilla is opposed at this point. I have two concerns with this
particular feature, that mostly came to light after the earlier
discussion:

1. I'm no longer convinced that influencing the control flow of
cross-origin contexts is a good idea without the cross-origin context
opting into that. That is, new sandboxing mechanisms should be done in
a way similar to CSP: EE.

Thanks, Anne -- I'm working up a spec change that should take that into account, for features which can alter control flow (and for which developers have no pre-existing expectation of failure, unlike, say, permissions).

Do you feel that document.domain falls under that umbrella, given that it's already restricted in sandboxed frames, and any frame could today be embedded without access to that API?

 

2. If we want to offer sites a primitive here for more isolation what
we need is to influence the creation of the agent cluster key as
described at https://github.com/whatwg/html/issues/4361. This needs to
be set when a document from an origin is first navigated to in a
browsing context group.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78jYgQHRHjMV6wL5TRR_%2BVO88B5qXw_T%3Dzaz-LUoTc53Uw%40mail.gmail.com.

[Anne van Kesteren]

On Mon, Mar 18, 2019 at 3:24 PM Ian Clelland <icle...@chromium.org> wrote:
> Do you feel that document.domain falls under that umbrella, given that it's already restricted in sandboxed frames, and any frame could today be embedded without access to that API?

It's not a 100% clear to me as when document.domain is disabled via
sandboxing some other things are disabled too, but perhaps those don't
end up mattering for this. The other concern still applies though.
Disabling document.domain isn't really what we want. What we want is
making it so that cross-origin-same-site globals get put in a new
agent cluster and that therefore breaking down the barrier between
globals within a single agent doesn't have any effect.

[Yoav Weiss]

On Mon, Mar 18, 2019 at 6:16 PM Anne van Kesteren <ann...@annevk.nl> wrote:

On Mon, Mar 18, 2019 at 3:24 PM Ian Clelland <icle...@chromium.org> wrote:
> Do you feel that document.domain falls under that umbrella, given that it's already restricted in sandboxed frames, and any frame could today be embedded without access to that API?

It's not a 100% clear to me as when document.domain is disabled via
sandboxing some other things are disabled too, but perhaps those don't
end up mattering for this.

It seems like you can allow (almost?) all other sandbox restrictions, such that blocking of document.domain without the iframe opting into it is (almost?) already exposed.

 

The other concern still applies though.
Disabling document.domain isn't really what we want. What we want is
making it so that cross-origin-same-site globals get put in a new
agent cluster and that therefore breaking down the barrier between
globals within a single agent doesn't have any effect.

That seems like a (potentially desirable) larger scope feature, which is not-necessarily mutually exclusive with what Mike is trying to ship here.

 

--
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/CADnb78jPtvZ4zGEsoD1Nv%2B0VMRtLnPRPS6YKtXPQJgfBWH_APQ%40mail.gmail.com.

[Yoav Weiss]

On Mon, Mar 18, 2019 at 9:21 AM Mike West <mk...@chromium.org> wrote:

Contact emails mk...@chromium.org Explainer https://github.com/w3c/webappsec-feature-policy/issues/241 Spec https://github.com/whatwg/html/pull/4170

Have you filed for a TAG review?

 

--

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/CAKXHy%3DcG7nHtmKhVZgbw3qewZAVOSja4eXPXBW0-8jttQfbaMA%40mail.gmail.com.

[Mike West]

Hey Anne! Thanks for the feedback!

I think there are two things that this policy aims to enable:

1.  It allows a document to harden its origin isolation by ensuring that it can't put itself into a state that would enable access for cross-origin-but-same-site documents.

2.  It serves as an input into user agents' decisions and heuristics around process isolation.

Each seems like a reasonable goal in itself.

To your points specifically:

1.  I don't actually have strong feelings about whether the policy should be allowed to flow into child frames, and I'm happy to defer to the ongoing discussion that Ian referred to earlier in the thread on that point. I think his point regarding sandbox's preexisting manipulation of a page's ability to use `document.domain` is pretty relevant to that conversation, and should be an input to the risk calculation (I think it's low).

2.  It does seem reasonable to poke more broadly at the agent cluster concept (which is new to me!), though it's not at all clear to me why that would be mutually exclusive with limiting access to `document.domain`. If we'd like to isolate two same-site frames from each other, surely we need to ensure that they can't reach into each other by setting `document.domain` to the same value? I believe that's the reason for step 6 of https://html.spec.whatwg.org/multipage/webappapis.html#same-agent-window-objects, right?

+Charlie Reis on the agent cluster point specifically, as they're closer to that code than I am, and will likely have well-informed opinions!

-mike

[Anne van Kesteren]

On Tue, Mar 26, 2019 at 3:21 PM Mike West <mk...@chromium.org> wrote:
> 1. It allows a document to harden its origin isolation by ensuring that it can't put itself into a state that would enable access for cross-origin-but-same-site documents.

As I'm trying to point out, this isn't actually guaranteed. Say A is
using this policy. A creates a same-origin popup B. B grabs references
to a whole bunch of objects from A. B then creates a
cross-origin-but-same-site subframe C and sets document.domain. C has
access to A's objects that B grabbed. (If Feature Policy is fixed so
this scenario no longer works, then consider A being embedded in
cross-site D and B being a sibling frame of A that does not have the
policy instead.)

> 2. It serves as an input into user agents' decisions and heuristics around process isolation.

I don't think that's possible without creating issues for the scenario
outlined above.

> 1. I don't actually have strong feelings about whether the policy should be allowed to flow into child frames, and I'm happy to defer to the ongoing discussion that Ian referred to earlier in the thread on that point. I think his point regarding sandbox's preexisting manipulation of a page's ability to use `document.domain` is pretty relevant to that conversation, and should be an input to the risk calculation (I think it's low).

I don't think Ian referenced anything?

> 2. It does seem reasonable to poke more broadly at the agent cluster concept (which is new to me!), though it's not at all clear to me why that would be mutually exclusive with limiting access to `document.domain`. If we'd like to isolate two same-site frames from each other, surely we need to ensure that they can't reach into each other by setting `document.domain` to the same value? I believe that's the reason for step 6 of https://html.spec.whatwg.org/multipage/webappapis.html#same-agent-window-objects, right?

It's the other way around. If they're agent cluster isolated, then
setting document.domain cannot do anything. (To be clear, you're
correct that it's not mutually exclusive with limiting access to
document.domain, but given finite time I don't see a reason to solve
both and live with the complexity of both as we need agent cluster
isolation for all the interesting things.)

[Mike West]

On Tue, Mar 26, 2019 at 3:38 PM Anne van Kesteren <ann...@annevk.nl> wrote:

On Tue, Mar 26, 2019 at 3:21 PM Mike West <mk...@chromium.org> wrote:
> 1.  It allows a document to harden its origin isolation by ensuring that it can't put itself into a state that would enable access for cross-origin-but-same-site documents.

As I'm trying to point out, this isn't actually guaranteed. Say A is
using this policy. A creates a same-origin popup B. B grabs references
to a whole bunch of objects from A. B then creates a
cross-origin-but-same-site subframe C and sets document.domain. C has
access to A's objects that B grabbed. (If Feature Policy is fixed so
this scenario no longer works, then consider A being embedded in
cross-site D and B being a sibling frame of A that does not have the
policy instead.)

I'm assuming the existence of Origin Policy (which I should have mentioned here), which would be able to impose an a priori constraint on both A and B. That was the context for the discussion we had in https://github.com/whatwg/html/pull/4170#issuecomment-438209931, and the context in which I think this policy would be most useful.

 

> 2.  It serves as an input into user agents' decisions and heuristics around process isolation.

I don't think that's possible without creating issues for the scenario
outlined above.

As above, Origin Policy applying Feature Policy is the heuristic that I think we were landing on in our earlier discussions.

> 1.  I don't actually have strong feelings about whether the policy should be allowed to flow into child frames, and I'm happy to defer to the ongoing discussion that Ian referred to earlier in the thread on that point. I think his point regarding sandbox's preexisting manipulation of a page's ability to use `document.domain` is pretty relevant to that conversation, and should be an input to the risk calculation (I think it's low).

I don't think Ian referenced anything?

Ian said he was "working up a spec change". Perhaps he can point it out? :)

 

> 2.  It does seem reasonable to poke more broadly at the agent cluster concept (which is new to me!), though it's not at all clear to me why that would be mutually exclusive with limiting access to `document.domain`. If we'd like to isolate two same-site frames from each other, surely we need to ensure that they can't reach into each other by setting `document.domain` to the same value? I believe that's the reason for step 6 of https://html.spec.whatwg.org/multipage/webappapis.html#same-agent-window-objects, right?

It's the other way around. If they're agent cluster isolated, then
setting document.domain cannot do anything. (To be clear, you're
correct that it's not mutually exclusive with limiting access to
document.domain, but given finite time I don't see a reason to solve
both and live with the complexity of both as we need agent cluster
isolation for all the interesting things.)

This policy was pretty straightforward to implement in Chrome, but I take your point about limited time. Is there a proposal for the kind of isolation you'd prefer that you can point me to?

-mike

[Ian Clelland]

On Tue, Mar 26, 2019 at 10:59 AM Mike West <mk...@chromium.org> wrote:

On Tue, Mar 26, 2019 at 3:38 PM Anne van Kesteren <ann...@annevk.nl> wrote:

On Tue, Mar 26, 2019 at 3:21 PM Mike West <mk...@chromium.org> wrote:
> 1.  It allows a document to harden its origin isolation by ensuring that it can't put itself into a state that would enable access for cross-origin-but-same-site documents.

As I'm trying to point out, this isn't actually guaranteed. Say A is
using this policy. A creates a same-origin popup B. B grabs references
to a whole bunch of objects from A. B then creates a
cross-origin-but-same-site subframe C and sets document.domain. C has
access to A's objects that B grabbed. (If Feature Policy is fixed so
this scenario no longer works, then consider A being embedded in
cross-site D and B being a sibling frame of A that does not have the
policy instead.)

I'm assuming the existence of Origin Policy (which I should have mentioned here), which would be able to impose an a priori constraint on both A and B. That was the context for the discussion we had in https://github.com/whatwg/html/pull/4170#issuecomment-438209931, and the context in which I think this policy would be most useful.

 

> 2.  It serves as an input into user agents' decisions and heuristics around process isolation.

I don't think that's possible without creating issues for the scenario
outlined above.

As above, Origin Policy applying Feature Policy is the heuristic that I think we were landing on in our earlier discussions.

> 1.  I don't actually have strong feelings about whether the policy should be allowed to flow into child frames, and I'm happy to defer to the ongoing discussion that Ian referred to earlier in the thread on that point. I think his point regarding sandbox's preexisting manipulation of a page's ability to use `document.domain` is pretty relevant to that conversation, and should be an input to the risk calculation (I think it's low).

I don't think Ian referenced anything?

Ian said he was "working up a spec change". Perhaps he can point it out? :)

That's the new discussion at https://github.com/w3c/webappsec-feature-policy/issues/288, modeled roughly on CSPEE. It's separate from the issue of whether document.domain should be such a feature which requires opt-in.

As Yoav mentioned, you can already limit document.domain with a sandbox which allows practically everything else (I think that plugins, domain and navigating-unrelated-browsing-contexts are the only three features which are always disabled in sandboxed frames)

[Mike West]

One other thing I didn’t mention: adding a policy gives us opportunities in the future to turn it off by default as part of a broader deprecation strategy (a la synchronous XHR). :)

-mike

--

-mike

[Anne van Kesteren]

On Tue, Mar 26, 2019 at 3:59 PM Mike West <mk...@chromium.org> wrote:
> I'm assuming the existence of Origin Policy (which I should have mentioned here), which would be able to impose an a priori constraint on both A and B. That was the context for the discussion we had in https://github.com/whatwg/html/pull/4170#issuecomment-438209931, and the context in which I think this policy would be most useful.

I'd argue that only in that case it's relevant and we shouldn't
support the other case as it gives a false sense of security. And then
also, we should define it in terms of agent cluster separation as
otherwise you cannot actually do process separation due to
SharedArrayBuffer (which would still required to be shareable, except
that doesn't work well cross-process across all platforms). As I've
tried to stress in various places, document.domain is just not the
boundary you all seem to think it is. Let's not further the idea that
it is.

[Ben Kelly]

I've been trying to read and catch up on this thread.... let me ask a question to see if I understand.

Anne, are you suggesting that we instead structure our feature policy around "please origin isolate me" and that would implicitly disable document.domain?  Is that what you mean by "If they're agent cluster isolated, then

setting document.domain cannot do anything"?

It seems if we did this we could reasonably flow the policy to same-origin subframes.  Cross-origin subframes would be in a separate agent cluster and could have a different document.domain policy?

Sorry if I've misunderstood.  Thanks.

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78g-jxsXDJy%3DhLnwBeM7ALoZy-ehBwMpohyvLJKf29tuKQ%40mail.gmail.com.

[Anne van Kesteren]

On Thu, May 2, 2019 at 3:59 PM Ben Kelly <wande...@chromium.org> wrote:
> Anne, are you suggesting that we instead structure our feature policy around "please origin isolate me" and that would implicitly disable document.domain? Is that what you mean by "If they're agent cluster isolated, then
> setting document.domain cannot do anything"?

Yeah, document.domain is all about getting access to more Window
objects within a window agent (which is always the sole window agent
within an agent cluster). If the window agent (cluster) is instead
scoped on origin, same-site-but-cross-origin Window objects would be
in different agents and so setting document.domain does not give
access.

> It seems if we did this we could reasonably flow the policy to same-origin subframes. Cross-origin subframes would be in a separate agent cluster and could have a different document.domain policy?

Since the keying is per browsing context group, it'd automatically
happen for subframes and popups.


Note also that since this discussion there's been more talk about
revamping Feature Policy a bit by separating out the sandbox-like
policies (see Feature Policy repository).

[Ben Kelly]

TL;DR: After further discussion with Anne offline I'd like to ask the API owners to PTAL at this intent to ship again.

Anne and I had a VC to discuss document.domain feature policy a couple weeks ago.  We covered a few different topics which I'll try to summarize here (Anne please correct if I get anything wrong):

1. There is a use case for this feature policy separate from origin isolation and security-oriented sandboxing.  Sites can use the FP to run experiments to audit the removal of document.domain from their product.  This is something they may wish to do before any additional isolation is enabled in order to measure impact separately.  I believe Anne agreed this was a separate and valid use case from origin isolation or sandboxing.

2. It probably makes sense to have a separate feature policy for opting-in to origin isolation.  Not only would that help clarify that its not an implicit benefit of document.domain, but it would have other benefits.  Origin isolation will also be somewhat observable through SAB transfers and agent cluster boundaries, so having an explicit feature would help keep browser behavior predictable for sites.  This isolation policy would probably need to be defined in terms of agent clusters so that the browser still has the flexibility to determine how many processes to actually create.

3. Finally, we discussed the planned feature policy refactoring described in:

https://github.com/w3c/webappsec-feature-policy/issues/282#issuecomment-486267212

The document.domain FP would fall into the "document sandboxing" category oriented towards removing "weird APIs".

Given that the new feature policy refactor does not have a clear timeline at the moment, we would prefer not to block shipping feature policies on its implementation.  

This is significant because it means there will probably be some behavior change when this new feature policy refactor is implemented.  Currently all policies, including document.domain, apply to child frames.  After the refactor "document sandboxing" policies like document.domain would only apply to the current document.

This change, however, does not seem like it will be breaking.  Its very unlikely that sites will come to depend on child frames throwing on document.domain assignment.  And the change will not really create a security problem because, as Anne pointed out above, document.domain FP is not an effective sandboxing technique without Origin Policy to apply it universally.

Also, it should not be a problem for child frames to lose access to document.domain as that is already possible today via sandboxed iframes.

With those points in mind we would like to move forward with shipping document.domain feature policy to help sites remove document.domain from their products.

Thanks.

Ben

[Charlie Reis]

This sounds good from my point of view (as a non-owner, but interested party).  I'm happy to see sites moving away from document.domain modifications.

For a bit of context, we've seen a big drop recently in the cases where document.domain modifications actually allow cross-origin scripting (to below 1% of page loads on June 1):

https://chromestatus.com/metrics/feature/timeline/popularity/2544

Charlie

[Ben Kelly]

One clarification.  When I wrote "we would like to move forward" the "we" is Google.  While Anne has not expressed a strong objection to this proposal so far, I didn't want to imply his full agreement here.  In particular, I expect he would prefer if we waited to ship any new feature policies until the infrastructure refactoring is complete.

[Yoav Weiss]

Thanks for all your work Ben on making sure we have a long term agreement and plan for this.

LGTM1

--

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/CAK7rkMh2q0NH0j0%3D3Thk31g%3DFM8KSQir2EhmGSKnNKCeO_9Hmw%40mail.gmail.com.

[Jochen Eisinger]

lgtm2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjiuVAkQpHpmiRfTLD-mwfgWAz7cMpNX9U8zAk8LN_Otw%40mail.gmail.com.

[Daniel Bratell]

LGTM3

/Daniel

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

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[Ben Kelly]

Thank you!

The feature policy is now enabled by default in ToT and will ship in Chrome 77.  I've updated the chromestatus entry.

[Anne van Kesteren]

On Thu, Jun 6, 2019 at 10:52 AM Yoav Weiss <yo...@yoav.ws> wrote:
> Thanks for all your work Ben on making sure we have a long term agreement and plan for this.

It's not entirely clear to me that's the case. I agreed there's a case
to be made for having reporting functionality around document.domain.
How exactly that should be expressed is as of yet unclear to me and
the change relative to what you plan on shipping today might be larger
than a behavior change, as far as I can tell. (Though this depends on
your definition of behavior too, I suppose.)