Add disallowdocumentaccess iframe attribute to force a creation of a new agent cluster map #4606

dtapuska · 2019-05-09T21:06:14Z

Add a disallowdocumentaccess iframe attribute to prevent access from one document to another.

Add steps that cause a newly created browsing context to either inherit the agent cluster map or
create a new one.

Given a nested browsing context (or child) with the disallowdocumentaccess parameter and an
iframe outside of the tree, the two browsing contexts will not be able to share data because
they will have different Agents (even if they are same-origin-domain).

Fixes #4435

At least two implementers are interested (and none opposed):
- …
- …
Tests are written and can be reviewed and commented upon at:
- …
Implementation bugs are filed:
- Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=961448
- Firefox: …
- Safari: …

(See WHATWG Working Mode: Changes for more details.)

💥 Error: Wattsi server error 💥

PR Preview failed to build. (Last tried on Jan 15, 2021, 7:59 AM UTC).

More

PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

🚨 Wattsi Server - Wattsi Server is the web service used to build the WHATWG HTML spec.

🔗 Related URL

<html>
<head><title>504 Gateway Time-out</title></head>
<body bgcolor="white">
<center><h1>504 Gateway Time-out</h1></center>
<hr><center>nginx/1.10.3</center>
</body>
</html>

If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.

dtapuska · 2019-05-09T21:07:18Z

@annevk @domenic
If this approach is ok. I'll continue iterating with tests and other implementation bugs.

domenic

Only a minor nit on my part. Otherwise, this seems to make sense to me, although @annevk is the expert.

I think the remaining "problem" is a preexisting one: that we only declaratively say "these agents are in the same cluster." For a long time @annevk and I have wanted to move to a model that explicitly allocates agents and agent clusters when new documents are created. That would make it clearer that at agent creation time, we consult the feature policy header/iframe's allow attribute, and use that to influence which agent cluster the agent goes in.

But, I see no problems with introducing this on top of the current paradigm. There is nothing introduced here that will make that future clarification harder to do.

This does mean we're closing the door on being able to deliver feature policy via in-document mechanisms like <meta>, since by that time it'll be too late (the agent will already be in its cluster). I suspect we're already pretty committed to that path, but /cc @clelland to make sure.

domenic · 2019-05-10T15:30:02Z

source

@@ -78127,6 +78130,8 @@ console.assert(iframeWindow.frameElement === null);
  <h5><dfn>IsPlatformObjectSameOrigin</dfn> ( <var>O</var> )</h5>

  <ol>
+   <li><p>If the <span>current global object</span> and <var>O</var> are not
+   <span>same-agent Window objects</span> return false.</p></li>


This doesn't work if O is a Location object. I think you want to check O's relevant global object.

Also, note how prevailing style is , then return X, not return X.

annevk

I don't think the primitives you're building this on are ready.

annevk · 2019-05-10T15:47:47Z

source

+   <li><p>If either <var>A</var>'s <span>relevant settings object</span>'s
+   <span>responsible document</span> or <var>B</var>'s <span>relevant settings object</span>'s
+   <span>responsible document</span> are not <span>allowed to use</span> the
+   "<code data-x="document-access">document-access</code>" feature, then return false.</p></li>


Feature Policy is being redesigned, so this doesn't quite fit I think, given https://github.com/w3c/webappsec-feature-policy/issues/282#issuecomment-486267212. This would be a sandboxing policy of sorts, but the exact framework for that isn't designed yet as per w3c/webappsec-permissions-policy#300.

Could this feature fit the permission-style model? I don't think it requires opt-in from an embedded page, as that page could have been loaded in isolation anyway, right?

It only fits if it's not allowed by default, which doesn't make sense? There's also no user involved which makes me rather wary as well.

annevk · 2019-05-10T15:52:32Z

Explicitly allocating agent clusters is tracked by #4361. All help welcome!

clelland · 2019-05-10T17:42:37Z

Re: declaring feature policy within HTML markup -- the one strong call we've had for this is for Client Hints. See @yoavweiss's and @eeeps's comments here. I'm not sure how late we can possibly defer the agent cluster allocation, by the time we're pre-scanning the document, can we still make that decision?

annevk · 2019-05-13T09:05:04Z

In theory and with sufficient refactoring of the HTML Standard, but I really don't think we should be designing for servers that cannot set headers anymore. We end up with a large number of edge cases that go undertested and underdefined and make it really hard to figure out what's going on.

yoavweiss · 2019-06-05T11:23:25Z

Apologies for not commenting here sooner.
I don't think this is just limited to Client Hints. Talking to e.g. analytics vendors about trying out feature policies for their customers in reporting-only mode, this is an industry-wide problem.

For deployment purposes, ideally we'd be able to turn on feature policies from script (e.g. by dynamically adding Feature Policy meta tags). That would mean that users that add <script src=fooanalytics.js> can magically also get reports regarding the feature policies that they violate, and those reports can evolve over time.

If the above is not feasible, having an HTML option would enable motivated front end devs to change their markup and add the required policies. Foo Analytics would also be able to add that piece to their published markup snippet, so that future devs will have that by default (even if that would tend to freeze in time the kind of FPs that they are tracking).

Finally, if only headers are supported, that means that only highly motivated developers with access to their backend code will be able to turn on FPs. So while making it easiest to specify and potentially implement (I haven't looked), it will be the worst option for the wide-scale deployment that we want Feature Policies to have.

eeeps · 2019-06-05T22:52:36Z

developers with access to their backend code

As Feature-Policies generally control front-end behavior, this seems especially worrying.

My biggest take away from the fact that 98% of devs, when given a choice, enabled Client Hints using HTML rather than HTTP, was not that Client Hints need HTML delivery, but rather that front-end-developers do.

This fundamentally should not change anything currently. All windows that have access to each other share the same agent so this is just an additional constant value to the string. When the agent is different (in a yet to be implemented change) this will fail the token checks even though the sites are the same origin. This matches what is proposed in the whatwg/html#4606 BUG=961448 Change-Id: Ic0be1e1ac5f231589924eab94d409d8a37c5f081 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1720712 Reviewed-by: Kentaro Hara <haraken@chromium.org> Commit-Queue: Dave Tapuska <dtapuska@chromium.org> Cr-Commit-Position: refs/heads/master@{#681362}

dtapuska · 2019-07-29T17:45:38Z

I've rebased this on top of the refactoring I've done for feature policy, and agent cluster definition (squashed commit of #4617) so hopefully this makes a whole lot more sense.

This does not address the request to specify this separation via meta tags which I believe is fundamentally impossible because the DOM is already created by then and this needs to be done before the Javascript global is created. I intend to proceed with an Intent to Implement and TAG review based on this current direction.

…olicy Intent to Implement: https://groups.google.com/a/chromium.org/d/msg/blink-dev/Cibo-GNPs7Y/RznlX7WKDAAJ Spec: whatwg/html#4606 BUG=961448 Change-Id: I3c2ff129a71a8ccb5a0015661770adc7ff22d14b

…olicy Intent to Implement: https://groups.google.com/a/chromium.org/d/msg/blink-dev/Cibo-GNPs7Y/RznlX7WKDAAJ Spec: whatwg/html#4606 BUG=961448 Change-Id: I3c2ff129a71a8ccb5a0015661770adc7ff22d14b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1726055 Commit-Queue: Dave Tapuska <dtapuska@chromium.org> Reviewed-by: Ken Buchanan <kenrb@chromium.org> Reviewed-by: Yuki Shiino <yukishiino@chromium.org> Reviewed-by: Ian Clelland <iclelland@chromium.org> Reviewed-by: Kentaro Hara <haraken@chromium.org> Cr-Commit-Position: refs/heads/master@{#688994}

…via document-access feature policy, a=testonly Automatic update from web-platform-tests Add ability to block same-origin access via document-access feature policy Intent to Implement: https://groups.google.com/a/chromium.org/d/msg/blink-dev/Cibo-GNPs7Y/RznlX7WKDAAJ Spec: whatwg/html#4606 BUG=961448 Change-Id: I3c2ff129a71a8ccb5a0015661770adc7ff22d14b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1726055 Commit-Queue: Dave Tapuska <dtapuska@chromium.org> Reviewed-by: Ken Buchanan <kenrb@chromium.org> Reviewed-by: Yuki Shiino <yukishiino@chromium.org> Reviewed-by: Ian Clelland <iclelland@chromium.org> Reviewed-by: Kentaro Hara <haraken@chromium.org> Cr-Commit-Position: refs/heads/master@{#688994} -- wpt-commits: 0221225c4e1863839c1505b7efe1230ff1d6ff34 wpt-pr: 18174

…via document-access feature policy, a=testonly Automatic update from web-platform-tests Add ability to block same-origin access via document-access feature policy Intent to Implement: https://groups.google.com/a/chromium.org/d/msg/blink-dev/Cibo-GNPs7Y/RznlX7WKDAAJ Spec: whatwg/html#4606 BUG=961448 Change-Id: I3c2ff129a71a8ccb5a0015661770adc7ff22d14b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1726055 Commit-Queue: Dave Tapuska <dtapuskachromium.org> Reviewed-by: Ken Buchanan <kenrbchromium.org> Reviewed-by: Yuki Shiino <yukishiinochromium.org> Reviewed-by: Ian Clelland <iclellandchromium.org> Reviewed-by: Kentaro Hara <harakenchromium.org> Cr-Commit-Position: refs/heads/master{#688994} -- wpt-commits: 0221225c4e1863839c1505b7efe1230ff1d6ff34 wpt-pr: 18174 UltraBlame original commit: 1e3822b202e3dd7622fc90c4638980d9dc037a46

dtapuska · 2020-02-11T15:50:27Z

We've pivoted a bit on this feature and are looking for it to be an iframe attribute instead. This causes a nested browsing context group to be created at the iframe itself and then causes all further nested browsing context groups to be in different agents and then they can't possibly share data only via 'postMessage'

annevk · 2020-02-11T15:56:32Z

I don't really understand how this works. A browsing context group exclusively holds top-level browsing contexts. Browsing contexts also cannot be same origin-domain or some such.

dtapuska · 2020-02-11T16:08:48Z

I don't really understand how this works. A browsing context group exclusively holds top-level browsing contexts. Browsing contexts also cannot be same origin-domain or some such.

What I am thinking is that the browsing context group doesn't hold a set of top-level browsing contexts but aset of browsing contexts. If you set the iframe attribute it will create a new nested browsing context group. This maps kind of what we have in Chrome with SiteInstance.

The alternate is to change the AgentClusterMap to be on the browser context itself instead of the group. Then when we create a nested browser context we can either inherit the agent cluster map or not.

annevk · 2020-02-11T16:20:02Z

From its name a SiteInstance pretty much has to be an agent cluster, I think. A browsing context holds a sequence of documents that can have different origins from each other.

dtapuska · 2020-02-11T18:36:52Z

From its name a SiteInstance pretty much has to be an agent cluster, I think. A browsing context holds a sequence of documents that can have different origins from each other.

Alright placed the agent cluster map on the browsingContext. Hopefully this makes sense then.

annevk · 2020-02-12T10:09:09Z

I don't really see how I'm afraid. If A1 popups A2, how would they share an agent cluster across two browsing contexts with this setup?

dtapuska · 2020-02-13T20:40:08Z

I don't really see how I'm afraid. If A1 popups A2, how would they share an agent cluster across two browsing contexts with this setup?

As discussed on IRC the browsing context inherits the same reference of the agent cluster map (I'm not sure exactly how to detail this in the spec).

After explanation these were your comments:
"I guess that makes sense; I'm still not a 100% on why we want to be doing this and am somewhat concerned that you can frame the top-level again and it being sandboxed from itself
Maybe we should couple this to #5273 somehow?
So I understand the effects of your proposal, it's just not clear to me it's worth doing on its own and if it's okay to do without opt-in of the affected sites"

document to another. Add steps that cause a newly created browsing context group at the iframe boundary. Fixes whatwg#4435

annevk · 2023-07-06T12:31:36Z

@dtapuska I suspect this can be closed?

domenic reviewed May 10, 2019

View reviewed changes

annevk reviewed May 10, 2019

View reviewed changes

domenic mentioned this pull request Jun 1, 2019

Feature policy pragma #4670

Open

3 tasks

dtapuska force-pushed the dom_access branch from d22ada2 to 94b8f7a Compare July 29, 2019 17:38

dtapuska mentioned this pull request Jul 29, 2019

Same-Origin iframe document-access limiting attribute w3ctag/design-reviews#397

Closed

5 tasks

chromium-wpt-export-bot mentioned this pull request Jul 30, 2019

Add ability to block same-origin access via document-access feature policy web-platform-tests/wpt#18174

Merged

dtapuska mentioned this pull request Aug 1, 2019

Limiting Same Origin Document Access mozilla/standards-positions#197

Closed

Malvoz mentioned this pull request Dec 7, 2019

Add document-access to proposed features w3c/webappsec-permissions-policy#351

Closed

dtapuska force-pushed the dom_access branch from 94b8f7a to 3bf6272 Compare February 11, 2020 15:44

dtapuska changed the title ~~Add a document-access feature policy to prevent access from one~~ Add disallowdocumentaccess iframe attribute to force a creation of a new *nested* browsing context group Feb 11, 2020

dtapuska force-pushed the dom_access branch from 3bf6272 to 8700908 Compare February 11, 2020 18:36

dtapuska changed the title ~~Add disallowdocumentaccess iframe attribute to force a creation of a new *nested* browsing context group~~ Add disallowdocumentaccess iframe attribute to force a creation of a new agent cluster map Feb 13, 2020

domenic mentioned this pull request Mar 6, 2020

JavaScript ShadowRealm proposal integration #5339

Closed

3 tasks

syg mentioned this pull request Mar 11, 2020

Concerns about Realms and Web standard goals tc39/proposal-shadowrealm#238

Closed

Add a disallowdocumentaccess iframe attribute to prevent access from one

118ca66

document to another. Add steps that cause a newly created browsing context group at the iframe boundary. Fixes whatwg#4435

dtapuska force-pushed the dom_access branch from 8700908 to 118ca66 Compare September 17, 2020 20:39

kiding mentioned this pull request Oct 22, 2020

iframe disallowdocumentaccess property Fyrd/caniuse#5663

Open

domenic mentioned this pull request Nov 16, 2020

Realms API ECMAScript Proposal w3ctag/design-reviews#542

Closed

2 tasks

Base automatically changed from master to main January 15, 2021 07:57

domenic force-pushed the main branch from 0947339 to 1b5099f Compare July 27, 2021 17:07

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add disallowdocumentaccess iframe attribute to force a creation of a new agent cluster map #4606

Add disallowdocumentaccess iframe attribute to force a creation of a new agent cluster map #4606

dtapuska commented May 9, 2019 •

edited by pr-preview bot

Loading

dtapuska commented May 9, 2019

domenic left a comment

domenic May 10, 2019

annevk left a comment

annevk May 10, 2019

clelland May 10, 2019

annevk May 13, 2019

annevk commented May 10, 2019

clelland commented May 10, 2019

annevk commented May 13, 2019

yoavweiss commented Jun 5, 2019 •

edited

Loading

eeeps commented Jun 5, 2019 •

edited

Loading

dtapuska commented Jul 29, 2019

dtapuska commented Feb 11, 2020

annevk commented Feb 11, 2020

dtapuska commented Feb 11, 2020

annevk commented Feb 11, 2020

dtapuska commented Feb 11, 2020

annevk commented Feb 12, 2020

dtapuska commented Feb 13, 2020

annevk commented Jul 6, 2023

Add disallowdocumentaccess iframe attribute to force a creation of a new agent cluster map #4606

Are you sure you want to change the base?

Add disallowdocumentaccess iframe attribute to force a creation of a new agent cluster map #4606

Conversation

dtapuska commented May 9, 2019 • edited by pr-preview bot Loading

💥 Error: Wattsi server error 💥

dtapuska commented May 9, 2019

domenic left a comment

Choose a reason for hiding this comment

domenic May 10, 2019

Choose a reason for hiding this comment

annevk left a comment

Choose a reason for hiding this comment

annevk May 10, 2019

Choose a reason for hiding this comment

clelland May 10, 2019

Choose a reason for hiding this comment

annevk May 13, 2019

Choose a reason for hiding this comment

annevk commented May 10, 2019

clelland commented May 10, 2019

annevk commented May 13, 2019

yoavweiss commented Jun 5, 2019 • edited Loading

eeeps commented Jun 5, 2019 • edited Loading

dtapuska commented Jul 29, 2019

dtapuska commented Feb 11, 2020

annevk commented Feb 11, 2020

dtapuska commented Feb 11, 2020

annevk commented Feb 11, 2020

dtapuska commented Feb 11, 2020

annevk commented Feb 12, 2020

dtapuska commented Feb 13, 2020

annevk commented Jul 6, 2023

dtapuska commented May 9, 2019 •

edited by pr-preview bot

Loading

yoavweiss commented Jun 5, 2019 •

edited

Loading

eeeps commented Jun 5, 2019 •

edited

Loading