Intent to Ship: disallowdocument access iframe attribute

[Dave Tapuska]

Contact emails

dtap...@chromium.org

Explainer

https://github.com/dtapuska/documentaccess

Spec

https://github.com/whatwg/html/pull/4606

The TAG review has been open for 6+ months without any comments:

https://github.com/w3ctag/design-reviews/issues/397

I'm hoping this I2S raises awareness around my intent to proceed.

Summary

Define an attribute on the iframe that causes a new Agent Cluster Map to be allocated at that point. Two frames that cross this barrier (one inside and one outside) will be in different Agents and therefore cannot share data with one another directly.

Link to “Intent to Prototype” blink-dev discussion

Intent to Prototype

Prototype feedback summary

We did not conduct an origin trial but prototyped some usage of the feature and that gave useful feedback. It was clear that the previous feature policy definition of it didn't work very well due to inheritance of document/feature policies. As this feature is about an embedding subtree being isolated.

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

Yes

Demo link

Demos are available in the WPT tests.

https://github.com/web-platform-tests/wpt/blob/master/html/browsers/windows/document-access/document_access_parent_access.tentative.html

Debuggability

Devtools will report a frame restriction error (different than a cross origin error).

Example:

"Uncaught DOMException: Blocked a restricted frame with origin "http://wpt.live" from accessing another frame."

Risks

Interoperability and Compatibility

Interoperability amongst browsers is not much of a risk here because this is restricting a feature that is available. If other vendors do not ship it those iframes will just have greater access than Chrome will grant.

To help with that I've taken great time in refining the navigation algorithm in the HTML spec and defining how agents and agent clusters are allocated. This spec is obviously a tweak on the agreed upon standard so far.

The main risk here is compatibility risk with the existing web and I've tried to address it in the explainer. While this is observable it is not understood to what extent one site will be influenced by the same site in another embedding tree. If others have ideas to quantify this risk I'd like to hear them. But the embedding properties are entirely upon the site doing the embedding (ie. they could apply sandbox flags or choose not to embed another document in the tree) so I find it hard to believe this will cause any breakage.

Edge: No Signals

Firefox: Mixed Signals.

https://github.com/mozilla/standards-positions/issues/197

https://github.com/whatwg/html/issues/5273

Safari: No Signals

Web / Framework developers: Positive. Internally at Google we have a few large customers looking into implementing this (Ads, AMP).

Ergonomics

No.

Activation

Activation is easy.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Yes, https://wpt.fyi/results/html/browsers/windows/document-access?label=experimental&label=master&aligned

Entry on the feature dashboard

https://chromestatus.com/feature/5648946183536640

[PhistucK]

It would be great if you resummarized this in simple, non-specification terms so that web developers could easily understand this intent...

I think there is a high interoperabie security risk here.

If I understand correctly, this is basically a security feature.

If websites depend on this security features (for security. Not as part of their logic or something like this that would throw exceptions and break the functionality of the website), write code while bearing it in mind and well and a result taking considerably less extraordinary measures to protect themselves as a result (this is the reality), this can create vulnerabilities that only exist in non-supporting browsers.

☆PhistucK

--
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/CAHgVhZWfguZ84iRYY7%3DRHvCcRc8Lr8YM3KWNY5_q%2BM4GdDTvVw%40mail.gmail.com.

[Boris Zbarsky]

On 2/14/20 11:56 AM, Dave Tapuska wrote:
> Firefox: Mixed Signals.
>
> https://github.com/mozilla/standards-positions/issues/197
>
> https://github.com/whatwg/html/issues/5273

Just to be clear, my questions there about use cases and actual behavior
and various spec interactions were not really addressed. "V8 does X"
does not count for the latter, to be clear.

I think "Negative signals" is closer to where things actually stand:
given the information presented so far we do not see the value of adding
a new security primitive here, and definitely do not see the value of
adding this _specific_ security primitive, especially given the
complexity it adds in various already-complex places in the spec.

-Boris

[Dave Tapuska]

> It would be great if you resummarized this in simple, non-specification terms so that web developers could easily understand this intent...

disallowdocumentaccess is an iframe attribute that prevents iframes at (or below) the point where is set from being able to access another iframe (outside of the point where the attribute was set) even if it is same origin. Basically think of the attribute creates a new security scope for the subtree.

> If I understand correctly, this is basically a security feature.

Yes it is a security feature. Website authors will still certainly need to understand the concerns for old (or non-supporting) browsers so it could create some interop problems.

And to speak to Boris' concern. Boris commented and hopefully I've addressed some of the concerns of Why? and Why this way? there.

dave.

[PhistucK]

In short, iFrame.contentWindow (or iFrame.contentDocument) would either throw or be null (same for window.parent in the iFrame). Right?

Or will the iFrame just behave as if it were cross-origin (so iFrame.contentWindow.postMessage and window.parent.postMessage would work)?

If the latter, I assume cookies, localStorage, sessionsStorage, service workers and so on are still shared?

☆PhistucK

--

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/CAHgVhZV8zSSkun9LQSTbWu2t-vHKYLyQw6zHQWq53UOgBQPxjw%40mail.gmail.com.

[Dave Tapuska]

It is the latter and you are correct regarding storage.

dave.

[sligh...@chromium.org]

Hey all,

Looks like there's some discussion on the TAG review still and questions about naming/mechanism. This is an area where there is a lot of contention between the various mechanisms; I've personally tried to whiteboard these in past TAG meetings to understand how they fit together, and a brand new attribute smells of trouble w/o some careful analysis. Can folks ping this thread back when all of those are resolved?

Regards

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Dave Tapuska]

W3C TAG came back indicating that it was a reasonable approach to the problem identified. I've reached out to Mozilla at the beginning of the week to confirm that their previous position (opposition) hasn't changed in light of the TAG feedback. Nonetheless I'd like to proceed with shipment in Chromium. W3C did bikeshed around the name, as Chromium authors have as well. I'd like to move forward with the original proposal.

dave.

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/CAHgVhZV8zSSkun9LQSTbWu2t-vHKYLyQw6zHQWq53UOgBQPxjw%40mail.gmail.com.

--

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/5e02902b-7c86-4bed-a207-1faee4855c51%40chromium.org.

[Dave Tapuska]

While a representative from Apple did provide feedback in the context of the W3C tag review. I've asked on webkit-dev what their position is: https://lists.webkit.org/pipermail/webkit-dev/2020-August/031340.html

dave.

[Yoav Weiss]

Thanks!

What's the status of the PR? Is it close to land?

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

[Dave Tapuska]

The status of the PR hasn't changed since the TAG review. I can look at rebasing it but it doesn't look like it will be merged because we don't have two vendor interest yet.

dave.

[Yoav Weiss]

Rebasing would be helpful.

[Yoav Weiss]

LGTM1 to ship conditional on rebasing the PR

Rebasing would be helpful.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

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

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5e02902b-7c86-4bed-a207-1faee4855c51%40chromium.org.

--
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+unsubscribe@chromium.org.

[Alex Russell]

LGTM2 with the same constraint.

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/CAHgVhZV8zSSkun9LQSTbWu2t-vHKYLyQw6zHQWq53UOgBQPxjw%40mail.gmail.com.

--
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/5e02902b-7c86-4bed-a207-1faee4855c51%40chromium.org.

--
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.

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/616d820f-a1bf-4eb3-8b54-886189b825c8n%40chromium.org.

[Dave Tapuska]

I recently got some emails questioning the status of this feature and I realized I didn't loop back on this thread. Before shipping we identified some interaction issues with service workers so we pulled the implementation and placed it on hold. It is believed fenced frames will serve the same goals. We will re-evaluate disallowdocumentaccess after fenced frames is completed.

dave.