srcdoc and sandbox interaction with session history

jakearchibald commented 3 years ago

First up is a simple one: Does setting srcdoc replace the current history entry or add a new one?

Chrome & Firefox: Replace if the current document url is about:srcdoc, otherwise add. Safari: Always replace.

I'm pretty sure Chrome & Firefox are doing the right thing here and it's somewhat spec'd.

How is a srcdoc entry stored in session history? It's currently unspec'd.

Test:

https://iframe-session-history.glitch.me/.
Set cookie: give all responses no-store (just to stop bfcache).
iframe-1: Set srcdoc to Math.random().
iframe-1: Navigate to 'one' via location object.
iframe-1: Set srcdoc to Math.random().

This creates history entries [srcdoc1, 'one', srcdoc2] in Chrome/Firefox and [srcdoc1, srcdoc2] in Safari.

Each browser behaves differently when traversing to the srcdoc entries.

Chrome: Recreates the document using the srcdoc of the iframe. As in srcdoc1 and srcdoc2 use the same source, which is different to the source srcdoc1 used when it was first created.

Firefox: Seems to store the srcdoc source along with the history entry, so srcdoc1 and srcdoc2 use different source, which is each the source they were created with.

Safari: Restores the original history entries in these places, as if the srcdoc stuff never happened.

Another test:

https://iframe-session-history.glitch.me/.
Set cookie: give all responses no-store (just to stop bfcache).
iframe-1: Set srcdoc to Math.random().
"Navigate to same origin page"
back()

Chrome: iframe empty. I guess this is because it looks at the srcdoc of the iframe which is empty, since the page has reloaded.

Firefox: Restores the iframe to its previous content.

Safari: Restores the iframe as if setting srcdoc never happened.

This seems consistent with the findings above. Firefox's model seems to make the most sense to me. Chrome's behaviour is ok I guess. Safari's behaviour is plain weird.

jakearchibald commented 3 years ago

Something I haven't looked at yet: When going back(), do the srcdoc iframes take their CSP rules from the parent as it is now, or as it was when the srcdoc page was created?

domenic commented 3 years ago

/cc @domfarolino @antosart for the CSP rules question. I am pretty sure that has a canonical answer as to how it should be, given recent policy container work.

antosart commented 3 years ago

I believe the answer for CSP rules depends on the answer to the main question (whether the srcdoc content is reloaded when navigating back or not).

If we store the content of srcdoc in history, we should also store the policies. If we reload the srcdoc attribute (which might have changed) on history navigations, then I guess we should also re-inherit the policies from the parent.

I believe the currently specced behaviour is to store the policies in history for srcdoc. This is also implemented in chrome.

(This is not tested for CSP at the moment I believe, although it is for referrer-policy, see the file referrer-policy/generic/inheritance/iframe-inheritance-history-about-srcdoc.html)

jakearchibald commented 3 years ago

If we store the content of srcdoc in history, we should also store the policies. If we reload the srcdoc attribute (which might have changed) on history navigations, then I guess we should also re-inherit the policies from the parent.

Agreed.

I believe the currently specced behaviour is to store the policies in history for srcdoc.

The spec doesn't seem to cover restoring srcdoc pages at all, unless I'm missing something.

This is also implemented in chrome.

I don't think so. See the tests above – it seems like Chrome goes back to the srcdoc defined in the page.

I tested Firefox, and it does seem to store the CSP rules along with the srcdoc src, so it's like it stores the whole response. That's what I'll spec for now, and we can look at it again later if needed.

antosart commented 3 years ago

I believe the currently specced behaviour is to store the policies in history for srcdoc.

The spec doesn't seem to cover restoring srcdoc pages at all, unless I'm missing something.

Sorry, I just meant w.r.t. policy inheritance (which might never be called because the spec does not cover navigating back to srcdoc). And I actually was mistaken: we explicitly excluded srcdoc when storing policies in history

This is also implemented in chrome.

I don't think so. See the tests above – it seems like Chrome goes back to the srcdoc defined in the page.

Also here I was referring to policies. Chrome reloads the srcdoc content from the srcdoc attribute, but stores and reloads the policies from history.

Back to the original question: if we store the content of the srcdoc attribute in history, then we should probably store other attributes as well (I am thinking at sandbox for example, or allow). I am not totally sure I am convinced that that is better than reloading everything on history navigations.

jakearchibald commented 3 years ago

I think it comes down to what you'd expect to happen here:

Navigate iframe to '/a'.
Set iframe sandbox attribute and navigate iframe to '/b'.
Press back.

Should '/a' be sandboxed?

antosart commented 3 years ago

Another good question! I am not sure.

For history navigations to srcdoc it seemed to be slightly more clear to me, in order to avoid the asymmetry of getting one attribute (srcdoc) back from history while re-parsing another one (sandbox) from the element, hence creating something potentially inconsistent.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/jakearchibald"><img src="https://avatars.githubusercontent.com/u/93594?v=4" />jakearchibald</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <p>Yeah it's a tough one, and I don't know enough about sandboxing. How about:</p> <ol> <li>Navigate iframe to '/a'.</li> <li>Navigate top level to another document.</li> <li>Press back, which reloads the previous page, and '/a' is reconnected to an iframe, but the iframe now has a sandbox attribute.</li> </ol> <p>It seems weird to load a non-sandboxed page into an iframe that was born with a sandbox attribute. Maybe reconnection just shouldn't happen in that case.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/domenic"><img src="https://avatars.githubusercontent.com/u/617481?v=4" />domenic</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <blockquote> <p>I think it comes down to what you'd expect to happen here:</p> </blockquote> <p>That's a tough one. On the one hand, I would expect '/a' not to be sandboxed since it was originally not sandboxed when loaded. On the other hand, I worry that that could allow some sort of sandbox escape. E.g. maybe the outer page expects that once it puts the sandbox attribute on the iframe, it's safe from its contents.</p> <blockquote> <p>Maybe reconnection just shouldn't happen in that case.</p> </blockquote> <p>This is my instinct.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/annevk"><img src="https://avatars.githubusercontent.com/u/1544111?v=4" />annevk</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <p>So, to summarize:</p> <ul> <li>Policies, including sandboxing policies (and probably anonymous iframes if they become a thing) are stored in history at creation-time</li> <li>For reconnection, attributes on the iframe (such as sandbox) also need to be part of the key, not just the URL</li> </ul> <p>I think that sounds pretty reasonable.</p> <p>cc @smaug---- </p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/jakearchibald"><img src="https://avatars.githubusercontent.com/u/93594?v=4" />jakearchibald</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <blockquote> <ul> <li>Policies, including sandboxing policies (and probably anonymous iframes if they become a thing) are stored in history at creation-time</li> </ul> </blockquote> <p>I think that's still a bit weird in this case:</p> <ol> <li>Load page1 in iframe</li> <li>Set sandbox attribute on iframe</li> <li>Navigate iframe to page2</li> <li>Back</li> </ol> <p>If we're saying that policies are stored with the history entry, that means loading page1 without sandboxing, into an iframe with the sandbox attribute set. Isn't that… confusing?</p> <p>If we were starting again, I think I'd want iframe history to be cleared if safety features changed.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/annevk"><img src="https://avatars.githubusercontent.com/u/1544111?v=4" />annevk</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <p>Yeah it is. I wonder if clearing history upon such an action would break anything in practice. Failing that, using the sandboxing rules at the time navigate is invoked is prolly best for that case. Is this something we should consider doing better on with new features such as <a href="https://github.com/camillelamy/explainers/blob/master/anonymous_iframes.md">https://github.com/camillelamy/explainers/blob/master/anonymous_iframes.md</a>? No breakage there yet.</p> <p>cc @camillelamy </p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/camillelamy"><img src="https://avatars.githubusercontent.com/u/33488028?v=4" />camillelamy</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <p>I think we're envisioning to look at the attribute every time we navigate, whether history or not. I thought this is what sandbox was doing? I would find it weird that an attribute set by the parent of the iframe for security purposes could be overwritten by the iframe's action of going back. I reckon that this looks weird from the iframe point-of-view, however in this case the iframe parent's choice of security attribute should be respected. Otherwise, we might risk a sandbox escape, or loading a regular document in a crossOriginIsolated context by error for the anonymous iframe case.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/annevk"><img src="https://avatars.githubusercontent.com/u/1544111?v=4" />annevk</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <p>@camillelamy yeah, I think that's a good fallback. The question is whether setting <code>sandbox</code> or <code>credentials</code> should reset the history as such actions impact the integrity of the nested browsing context.</p> <p>Although I'm not entirely sure how that would work. In the example from <a href="https://github.com/whatwg/html/issues/6809#issuecomment-884227242">https://github.com/whatwg/html/issues/6809#issuecomment-884227242</a> it would be reset in step 2, but presumably you still need a current history entry so would it really solve anything? @jakearchibald what was the model you had in mind?</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/jakearchibald"><img src="https://avatars.githubusercontent.com/u/93594?v=4" />jakearchibald</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <p>@camillelamy</p> <blockquote> <p>I think we're envisioning to look at the attribute every time we navigate, whether history or not.</p> </blockquote> <p>Doesn't that leave you with the other problem?</p> <ol> <li>Page has an iframe without the sandbox attr.</li> <li>Page wants to load a risky page in the iframe, so it sets the sandbox attr.</li> <li>Page loads the risky page in the iframe.</li> <li>Top level navigation.</li> <li>Back.</li> </ol> <p>This results in the risky page being reparented in an iframe without sandboxing.</p> <p>Or:</p> <ol> <li>Page has an iframe with the sandbox attr, containing a risky page.</li> <li>Page wants to load a safe page in the iframe, so it removes the sandbox attr.</li> <li>Page loads safe page the iframe.</li> <li>Back.</li> </ol> <p>This results in the risky page loading in an unsandboxed iframe.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/jakearchibald"><img src="https://avatars.githubusercontent.com/u/93594?v=4" />jakearchibald</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <p>@annevk </p> <blockquote> <p>In the example from <a href="https://github.com/whatwg/html/issues/6809#issuecomment-884227242">#6809 (comment)</a> it would be reset in step 2, but presumably you still need a current history entry so would it really solve anything? @jakearchibald what was the model you had in mind?</p> </blockquote> <p>I was thinking the history clearing would happen in step 3, as that's the moment new sandboxing rules would be applied to the iframe. The spec would go "wait, the policy has changed!" and cycle the navigable before continuing (as if the iframe had been removed and readded in the same place).</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/camillelamy"><img src="https://avatars.githubusercontent.com/u/33488028?v=4" />camillelamy</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <blockquote> <p>@camillelamy</p> <blockquote> <p>I think we're envisioning to look at the attribute every time we navigate, whether history or not.</p> </blockquote> <p>Doesn't that leave you with the other problem?</p> <ol> <li>Page has an iframe without the sandbox attr.</li> <li>Page wants to load a risky page in the iframe, so it sets the sandbox attr.</li> <li>Page loads the risky page in the iframe.</li> <li>Top level navigation.</li> <li>Back.</li> </ol> <p>This results in the risky page being reparented in an iframe without sandboxing.</p> </blockquote> <p>If there is a top-level navigation, then back, we would reload the top-level document. It might then recreate or not recreate the iframe, with whatever sandbox flag it wants, and then load whatever it wants inside. I don't see how this necessarily leads to reparenting the risky page.</p> <blockquote> <p>Or:</p> <ol> <li>Page has an iframe with the sandbox attr, containing a risky page.</li> <li>Page wants to load a safe page in the iframe, so it removes the sandbox attr.</li> <li>Page loads safe page the iframe.</li> <li>Back.</li> </ol> <p>This results in the risky page loading in an unsandboxed iframe.</p> </blockquote> <p>I would argue that it is probably not good security practice to set sandbox flags on iframe and then remove them...</p> <p>For the history clearing part, would this apply to the history list the browser maintains (not really specced AFAIU) or just the history API available to the document? Because if the later, wouldn't there still be a problem when the user clicks on the back button?</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/jakearchibald"><img src="https://avatars.githubusercontent.com/u/93594?v=4" />jakearchibald</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <p>@camillelamy </p> <blockquote> <p>I don't see how this necessarily leads to reparenting the risky page.</p> </blockquote> <p>Unfortunately that's what happens. To reproduce:</p> <ol> <li>Go to <a href="https://iframe-session-history.glitch.me/">https://iframe-session-history.glitch.me/</a></li> <li>Click "Set-cookie: give all responses no-store" in the cookies column (to disable bfcache)</li> <li>Click "Set-cookie: give iframe2 sandbox attr" in the cookies column. This serves the second iframe with a sandbox attribute.</li> <li>Refresh the page. The second iframe should display iframe-2-start. It won't display "(script allowed)" since it's sandboxed.</li> <li>Press "Navigate to 'one'" in the iframe-2 column. That loads "one" in the sandboxed iframe.</li> <li>Press "unset all" in the cookie column. That means the iframe won't have the sandbox attribute the next time it loads.</li> <li>"navigate to same origin page" - this navigates the top level away.</li> <li>Press the browser back button.</li> </ol> <p>"one" will be reparented into the second iframe, but it's no longer sandboxed.</p> <p>Reparenting logic is different across browsers, and unspec'd. In Firefox it seems to just use index in the source to reconnect iframes, so it's fairly possible to end up with content reloading in the wrong iframe, which may have a weaker policy.</p> <p>At a minimum, I think we need to avoid reparenting in cases like this, although I'm not 100% sure what the logic would be.</p> <blockquote> <p>I would argue that it is probably not good security practice to set sandbox flags on iframe and then remove them</p> </blockquote> <p>Yeah, I think you're right. Maybe solving the reparenting case is enough. Although, the "clearing history" fix seems easy enough, and if it protects folks, it might be worth it?</p> <blockquote> <p>For the history clearing part, would this apply to the history list the browser maintains (not really specced AFAIU) or just the history API available to the document?</p> </blockquote> <p>It'd be the browser history list (I'm working on a better spec for that in <a href="https://github.com/whatwg/html/pull/6315">https://github.com/whatwg/html/pull/6315</a>). But, it'd work the same as removing and readding the iframe, since that flushes iframe history.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/camillelamy"><img src="https://avatars.githubusercontent.com/u/33488028?v=4" />camillelamy</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <p>Treating it as if the iframe was removed an re-added when we change security properties of the frame seems reasonable to me.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/camillelamy"><img src="https://avatars.githubusercontent.com/u/33488028?v=4" />camillelamy</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <p>cc @ArthurSonzogni @antosart</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/camillelamy"><img src="https://avatars.githubusercontent.com/u/33488028?v=4" />camillelamy</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <p>cc @iVanlIsh</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/ArthurSonzogni"><img src="https://avatars.githubusercontent.com/u/4759106?v=4" />ArthurSonzogni</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <p>Firefox behavior of storing srcdoc into the history entry is interesting.</p> <p>At some point, we are going to isolate sandboxed document in their own process. Since we are going to make srcdoc content to move across processes, we might benefits from copying Firefox behavior here along the way. I remember in this internal doc, I mentioned doing it as an alternative: <a href="https://docs.google.com/document/d/1YHWET0-Q8fh-i78DCMYowZFXtaXogYrIEhcKHKcCZbA/edit#heading=h.42t66nhl3wkw">https://docs.google.com/document/d/1YHWET0-Q8fh-i78DCMYowZFXtaXogYrIEhcKHKcCZbA/edit#heading=h.42t66nhl3wkw</a> but said this would introduce a breaking change with this scenario:</p> <pre><code>Set srcdoc = ”A” Set src = “https://example. Set srcdoc = ”B” history.back(-2)</code></pre> <p>Actually, by reading this thread, I realize the breaking change would actually mean converging with Firefox here. That might turns out to be a nice outcome. +CC @wjmaclean, Alex Moshchuk (can't find GitHub handle right now), @csreis. FYI.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/jakearchibald"><img src="https://avatars.githubusercontent.com/u/93594?v=4" />jakearchibald</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>Some more findings:</p> <hr /> <p>Test:</p> <ol> <li><a href="https://iframe-session-history.glitch.me/">https://iframe-session-history.glitch.me/</a></li> <li>iframe-1: Set srcdoc to Math.random() - add or replace?</li> <li>iframe-1: Set srcdoc to Math.random() - add or replace?</li> </ol> <p>Chrome, Firefox: add replace Safari: replace replace</p> <p>It seems like Chrome & Firefox treat it as a replacement since the url is <code>about:srcset</code> in each case. I'm not sure why Safari does what it does.</p> <p>There's a good case to be made for each srcdoc change being an 'add', but I guess spec'ing what Chrome & Firefox do is fine.</p> <hr /> <p>Test:</p> <ol> <li><a href="https://static-misc-3.glitch.me/srcdoc-target-test/">https://static-misc-3.glitch.me/srcdoc-target-test/</a></li> <li>Click link - add or replace?</li> <li>Change srcdoc to random number - add or replace?</li> </ol> <p>Chrome, Firefox: add add Safari: replace replace</p> <p>Chrome and Firefox are consistent with the previous finding. In this case it's an 'add' because the url is changing from <code>about:srcset#yo</code> to <code>about:srcset</code>, which is consistent with the findings in <a href="https://github.com/whatwg/html/issues/6682">https://github.com/whatwg/html/issues/6682</a>.</p> <p>Chrome: The back button doesn't work as I'd expect, but it's consistent with findings in the OP. Firefox: The back button takes you to an error page. I guess it doesn't like <code>about:srcdoc#yo</code>, even though it was fine with it previously.</p> <p>I'll spec it so the back button changes the document, like we see from Firefox apart from the error case.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/ArthurSonzogni"><img src="https://avatars.githubusercontent.com/u/4759106?v=4" />ArthurSonzogni</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>PSA: 1) Firefox stores the srcdoc content in history and reloads it from history. 2) Chrome reloads the srcdoc content from the iframe srcdoc attribute (which might have changed in between).</p> <p>It seems we might have reached the conclusion to move toward Firefox behavior. If yes, it means restoring the PolicyContainer from history also makes some sense. Anyway, it seems this is already what Chrome and Firefox are doing: I checked behavior for CSP (<a href="https://wpt.fyi/results/content-security-policy/inheritance/iframe-srcdoc-history-inheritance.html?label=experimental&label=master&aligned">see wpt results</a>).</p> <p>I initially wanted to align <a href="https://chromium-review.googlesource.com/c/chromium/src/+/3735285">Chrome with the spec</a>, but I am now believing I should align the spec/WPT with Chrome and Firefox. I am going to propose a PR removing step 2 from: <a href="https://html.spec.whatwg.org/multipage/origin.html#requires-storing-the-policy-container-in-history">https://html.spec.whatwg.org/multipage/origin.html#requires-storing-the-policy-container-in-history</a> Please let me know if you disagree.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/domenic"><img src="https://avatars.githubusercontent.com/u/617481?v=4" />domenic</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>So what are all the behaviors this bug is covering?</p> <ul> <li><a href="https://github.com/whatwg/html/issues/6809#issue-931716900">Original post first test</a>: resolved to Chrome/Firefox behavior in #6315. No WPTs yet?</li> <li><a href="https://github.com/whatwg/html/issues/6809#issue-931716900">Original post traversal question</a>: resolved to Firefox behavior in #6315. No WPTs yet?</li> <li><a href="https://github.com/whatwg/html/issues/6809#issue-931716900">Original post second test</a>: resolved to Firefox behavior, however this depends on iframe reconnection, which is not specced in #6315. No tests yet.</li> <li>Policy container policies during history traversal: resolved in <a href="https://github.com/whatwg/html/pull/8057">https://github.com/whatwg/html/pull/8057</a> to Chrome behavior, with tests for both CSP and referrer policy. (Firefox restores CSP but not yet referrer policy.)</li> <li>Sandboxing: not sure what the resolution is.</li> <li><a href="https://github.com/whatwg/html/issues/6809#issuecomment-905677979">Some more findings first test</a>: resolved to Chrome/Firefox behavior in both existing spec and #6315. Needs WPTs.</li> <li><a href="https://github.com/whatwg/html/issues/6809#issuecomment-905677979">Some more findings second test</a>: resolved to Firefox-ish behavior in #6315. Needs WPTs.</li> </ul> <p>I will work on some WPTs. If someone could help clarify the desired resolution for sandboxing that'd be great as well.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/jakearchibald"><img src="https://avatars.githubusercontent.com/u/93594?v=4" />jakearchibald</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>Summary of the sandbox options:</p> <h2>Option 1: The rules from the sandbox attr are used when navigating an iframe</h2> <p>Pros: It's what browsers do now!</p> <p>Risk: If a developer loads an unsafe page in a sandboxed iframe, then removes sandbox and loads a safe page, it's possible through traversal that the unsafe page loads without a sandbox.</p> <p>Risk: If a page loads with a safe page in an iframe, then adds a sandbox to load an unsafe page, it's possible through iframe reparenting that the unsafe page loads without a sandbox.</p> <p>Risk: A page loads with an unsafe page in an iframe. It's possible through iframe reparenting, that the heuristics don't quite work, and the unsafe page ends up reparenting into a 'different' iframe without a sandbox.</p> <p>Risk: Inconsistent results if we start pulling iframe documents from bfcache.</p> <h2>Option 2: The sandbox rules are stored in the history entry</h2> <p>Pros: Follows what we've decided to do with srcdoc and other policy state.</p> <p>Risk: It's a change in behaviour, so could be a compat issue.</p> <p>Risk: The developer sets a <code>sandbox</code> attribute, then traverses the iframe, and is confused that the rules aren't applied. I don't think this is a security risk. This seems less risky than option 1. Although the developer may expect stronger sandboxing to be in place, since it's a traversal it means they must have already loaded the page with no sandbox.</p> <h2>Option 3: History clearing and & reparenting failing</h2> <p>This solution has two parts:</p> <ul> <li>If an iframe navigates with new sandbox rules, its other history entries are cleared.</li> <li>If an iframe would reparent into an iframe with different sandbox rules to the original iframe, the reparenting fails.</li> </ul> <p>Pros: Avoids pages loading with unexpected sandbox rules.</p> <p>Risk: It's a change in behaviour, so could be a compat issue.</p> <hr /> <p>Maybe option 2 is the right balance of safe & simple?</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/smaug----"><img src="https://avatars.githubusercontent.com/u/9219935?v=4" />smaug----</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>I and @petervanderbeken happened to discuss about this and also prefer option 2 of those three options (and the way Firefox stores srcdoc). Should be relatively easy to implement and hopefully not too surprising for the web devs.</p> </div> </div> <div class="page-bar-simple"> </div> <div class="footer"> <ul class="body"> <li>© <script> document.write(new Date().getFullYear()) </script> Githubissues.</li> <li>Githubissues is a development platform for aggregating issues.</li> </ul> </div> <script src="https://cdn.jsdelivr.net/npm/jquery@3.5.1/dist/jquery.min.js"></script> <script src="/githubissues/assets/js.js"></script> <script src="/githubissues/assets/markdown.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/highlight.min.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/languages/go.min.js"></script> <script> hljs.highlightAll(); </script> </body> </html>

whatwg / html

srcdoc and sandbox interaction with session history #6809