Closed zcorpan closed 7 years ago
@clelland FYI
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?
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.
@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.
@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:
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 :)
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?
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.
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. :-)
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?
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
OK, so it sounds like we should be sure to not allow paymentrequests (etc.) automatically on same-origin sandboxed iframes, if I am understanding correctly. You still need allowpaymentrequest=""
for those, and for their descendants.
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.
Ah I see how it works now. OK, cool, so we don't need to worry about that explicitly then.
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.
What about this case:
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>
https://sub.example.org/b.html
<!doctype html>
<script> document.domain = "example.org"; </script>
Can b.html go fullscreen and request payments? It can reach its parent's DOM.
I think having b.html not able to go fullscreen in that case is fine. A bit more worrying is this case:
<!doctype html>
<script> document.domain = "example.org"; </script>
<iframe src="https://example.org/b.html"></iframe>
in which b.html can't access the parent's DOM and arguably shouldn't be allowed to go fullscreen...
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.
In general, I'm not sure there are any "good" ways of making this stuff play nice with document.domain.
The origin check seems like it would need to be live in order to disallow your example. Right?
I agree though that it's fine to disallow when document.domain is used and the origins' hosts are different.
The origin check seems like it would need to be live in order to disallow your example. Right?
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.
If the parent sets document.domain after 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...
If the parent sets document.domain after the subdocument is created
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.
New question, should b.html
be allowed to make payments?
https://example.org/a.html
<!doctype html>
<object data="b.html"></object>
(i.e. when the browsing context container is not an iframe
element)
And the same question applies to <embed>
and <frame>
containers; all four are considered same-origin and can access their parent context's DOM.
It's probably slightly more work to specifically exclude embed
/frame
/object
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 allow*
attributes on those elements.
I think it'd be good to "accidentally" support same-origin embed
/frame
/object
. There was a recent case with a site using frameset
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.
@foolip OK, that's what https://github.com/whatwg/html/pull/2217 does (for allowpaymentrequest
).
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