"Allowed to use" should allow same-origin without the attribute

zcorpan commented 7 years ago

This is to match Feature Policy and because same-origin can just set the attribute anyway.

See https://github.com/w3c/browser-payment-api/pull/383#issuecomment-267338591

foolip commented 7 years ago

@clelland FYI

foolip commented 7 years ago

This was also discussed in https://github.com/w3c/mediacapture-main/issues/268#issuecomment-231045430.

I would like to see a path for defining the allow* attributes entirely in terms of Feature Policy, but https://github.com/whatwg/html/issues/1481 and https://bugzilla.mozilla.org/show_bug.cgi?id=1283526 make this hard.

For the other attributes, though, I wonder if it can be done, to get the alignment for free?

domenic commented 7 years ago

I think part of the issue is that feature policy is not really well-defined yet, especially for the kind of edge cases we're considering here, so we're pioneering the definitions in the allow* attributes and then feature policy will likely adopt our work.

But it does sound like fullscreen has some web-compat issues that make this tricky. Maybe what we'll want is some kind of "legacy web-compat semantics flag" to allow fullscreen to do something slightly different.

clelland commented 7 years ago

@domenic, what do you think needs to be defined better in feature policy? I'm planning on moving the algorithms and updated descriptions back from our 'specsplainer' into the actual spec for next week, and if you think there are specific edge cases that still need addressing, then I'll ensure that they are.

But it does sound like fullscreen has some web-compat issues that make this tricky. Maybe what we'll want is some kind of "legacy web-compat semantics flag" to allow fullscreen to do something slightly different.

Agreed that fullscreen may need special handling for compatibility issues, but I'd really like to avoid having to do that for other attributes if possible.

domenic commented 7 years ago

@clelland well, I hadn't looked at it in a while, so maybe it is better now. But there not being a spec definitely implied to me it was not well-defined.

It seems like the interesting edge cases identified so far are around:

Not being in a fully active document
Having one or more cross-origin documents in the chain, even if both the top-level document and the document trying to use the feature are same-origin
Payment request at least wants to allow same-origin usage even without feature policy/allowpaymentrequest in play, which seems exceptional (and is not how fullscreen and usermedia work, from what I understand)
What happens when the attribute changes: apparently for feature policy the plan is to snapshot it at iframe creation time

But browsing the threads it looks like you are pretty aware of all this and on top of it, and @bzbarsky and @zcorpan are helping, so I think things are in good hands. I'll leave you all too it :)

bzbarsky commented 7 years ago

but #1481 and https://bugzilla.mozilla.org/show_bug.cgi?id=1283526 make this hard.

Hrm. I thought I had a reason for my general unease around fullscreen! That said, I just looked at the imdb page and I don't see them obviously using allowfullscreen on any iframes now. So it's possible they redesigned their page. Given that, maybe it's worth trying to switch everyone to the snapshotting behavior again; it really is much saner. @upsuper am I missing something on the imdb page?

upsuper commented 7 years ago

It seems to me IMDb has updated their page and it no longer uses iframe to show the video, so switching the behavior would no longer regress that page. But the question is whether that is the only page broken by this switch, which I have no idea.

If we decide to switch the behavior, I hope all browsers can coordinate to switch at roughly the same time, so that if any website is regressed, we can ask them to fix their website, rather than changing our behavior back and forth.

Given we have switched the behavior in the past, I suppose it is easy for us to do (just need to rebase some patches). So I'd like to hear whether other vendors are willing to coordinate on this.

zcorpan commented 7 years ago

Snapshot PR is https://github.com/whatwg/html/pull/2187 - let's continue discussion there. This issue is about allowing same-origin without an attribute. :-)

domenic commented 7 years ago

Getting this back on topic, what are our thoughts on making all these allow* things automatically allowed when same-origin?

Does sandboxing affect things? E.g. what if the iframe is an <iframe sandbox> without allow-same-origin? Can the contents of the iframe still reach up and toggle the attribute?

bzbarsky commented 7 years ago

Can the contents of the iframe still reach up and toggle the attribute?

No, and neither is that case same-origin. So it would work just like in terms of allow* attributes.</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> 7 years ago</strong> </div> <div class="markdown-body"> <p>OK, so it sounds like we should be sure to <strong>not</strong> allow paymentrequests (etc.) automatically on same-origin <em>sandboxed</em> iframes, if I am understanding correctly. You still need <code>allowpaymentrequest=""</code> for those, and for their descendants.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/bzbarsky"><img src="https://avatars.githubusercontent.com/u/1457979?v=4" />bzbarsky</a> commented <strong> 7 years ago</strong> </div> <div class="markdown-body"> <p>The point is, that once you are sandboxed without "allow-same-origin" you are no longer same-origin. So any spec text that keys off "same origin" will not apply to you.</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> 7 years ago</strong> </div> <div class="markdown-body"> <p>Ah I see how it works now. OK, cool, so we don't need to worry about that explicitly then.</p> <p>We're back to the question of whether implementations want to start allowing fullscreen/usermedia/paymentrequests on same-origin iframes even without their allow* attributes.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/zcorpan"><img src="https://avatars.githubusercontent.com/u/244772?v=4" />zcorpan</a> commented <strong> 7 years ago</strong> </div> <div class="markdown-body"> <p>What about this case:</p> <pre><code>https://example.org/a.html (top-level browsing context) <!doctype html> <script> document.domain = "example.org"; </script> <iframe src="https://sub.example.org/b.html"></iframe></code></pre> <pre><code>https://sub.example.org/b.html <!doctype html> <script> document.domain = "example.org"; </script></code></pre> <p>Can b.html go fullscreen and request payments? It can reach its parent's DOM.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/bzbarsky"><img src="https://avatars.githubusercontent.com/u/1457979?v=4" />bzbarsky</a> commented <strong> 7 years ago</strong> </div> <div class="markdown-body"> <p>I think having b.html not able to go fullscreen in that case is fine. A bit more worrying is this case:</p> <pre><code><!doctype html> <script> document.domain = "example.org"; </script> <iframe src="https://example.org/b.html"></iframe></code></pre> <p>in which b.html <em>can't</em> access the parent's DOM and arguably shouldn't be allowed to go fullscreen...</p> <p>Note that if the allow flag snapshots ancestor state at document creation time, then in your situation it would see the two pages as different-origin and different effective script origin or whatever that thing is called now.</p> <p>In general, I'm not sure there are any "good" ways of making this stuff play nice with document.domain.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/zcorpan"><img src="https://avatars.githubusercontent.com/u/244772?v=4" />zcorpan</a> commented <strong> 7 years ago</strong> </div> <div class="markdown-body"> <p>The origin check seems like it would need to be live in order to disallow your example. Right?</p> <p>I agree though that it's fine to disallow when document.domain is used and the origins' hosts are different.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/bzbarsky"><img src="https://avatars.githubusercontent.com/u/1457979?v=4" />bzbarsky</a> commented <strong> 7 years ago</strong> </div> <div class="markdown-body"> <blockquote> <p>The origin check seems like it would need to be live in order to disallow your example. Right?</p> </blockquote> <p>If it checked effective script origin stuff, then no. It would just always treat loads in subframes as different-origin (because the parent has .domain set and the subframe does not at that point yet). The resulting behavior would be somewhat confusing, I agree.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/zcorpan"><img src="https://avatars.githubusercontent.com/u/244772?v=4" />zcorpan</a> commented <strong> 7 years ago</strong> </div> <div class="markdown-body"> <p>If the parent sets document.domain <em>after</em> the subdocument is created, and the subdocument does not set it at all, then a snapshot of the origin would allow the features but they can't access each other's DOMs (after the parent had set document.domain). But maybe that is OK...</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/bzbarsky"><img src="https://avatars.githubusercontent.com/u/1457979?v=4" />bzbarsky</a> commented <strong> 7 years ago</strong> </div> <div class="markdown-body"> <blockquote> <p>If the parent sets document.domain after the subdocument is created</p> </blockquote> <p>Then the subdocument can have added the attribute before the parent set document.domain, so the parent has no expectation of security in this situation, and allowing seems fine.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/zcorpan"><img src="https://avatars.githubusercontent.com/u/244772?v=4" />zcorpan</a> commented <strong> 7 years ago</strong> </div> <div class="markdown-body"> <p>New question, should <code>b.html</code> be allowed to make payments?</p> <pre><code>https://example.org/a.html <!doctype html> <object data="b.html"></object></code></pre> <p>(i.e. when the browsing context container is not an <code>iframe</code> element)</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/clelland"><img src="https://avatars.githubusercontent.com/u/45853?v=4" />clelland</a> commented <strong> 7 years ago</strong> </div> <div class="markdown-body"> <p>And the same question applies to <code><embed></code> and <code><frame></code> containers; all four are considered same-origin and can access their parent context's DOM.</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> 7 years ago</strong> </div> <div class="markdown-body"> <p>It's probably slightly more work to specifically exclude <code>embed</code>/<code>frame</code>/<code>object</code> elements since you are just looking at the parent browsing context so making the same-origin case work seems okay (though I'd be okay with explicitly forbidding it too). However, we shouldn't support the <code>allow*</code> attributes on those elements.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/foolip"><img src="https://avatars.githubusercontent.com/u/498917?v=4" />foolip</a> commented <strong> 7 years ago</strong> </div> <div class="markdown-body"> <p>I think it'd be good to "accidentally" support same-origin <code>embed</code>/<code>frame</code>/<code>object</code>. There was a recent case with a site using <code>frameset</code> where a user was upset that the Fullscreen button had disappeared from the videos, and it was because they were in frames. I suspect that case would start working again.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/zcorpan"><img src="https://avatars.githubusercontent.com/u/244772?v=4" />zcorpan</a> commented <strong> 7 years ago</strong> </div> <div class="markdown-body"> <p>@foolip OK, that's what <a href="https://github.com/whatwg/html/pull/2217">https://github.com/whatwg/html/pull/2217</a> does (for <code>allowpaymentrequest</code>).</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

"Allowed to use" should allow same-origin without the attribute #2184