-
Notifications
You must be signed in to change notification settings - Fork 153
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Policies in data: urls #374
Comments
This idea would require origin snapshotting, right? I suppose if we defined an initial origin for the browsing context and always used that it could maybe work. There's also the case of the embedded document sandboxing itself. If the embedder would use cc @johannhof |
I think that it would require that -- I still have whatwg/html#4766 open, though it might need some rebasing; I haven't looked at it in quite a while. I'm not sure how the second point intersects with data: urls; they are just content, without headers, so shouldn't be able to alter their inherited policy at all. For cases with HTTP transport, that is a good question, though. I can think of reasons to expect just that behaviour, but perhaps it should be a separate issue. |
It's mostly that maybe we shouldn't consider the origin contained in |
That would cover everything except HTTP-level redirects with tuple origins, I expect. |
It's not working for me in Chrome or Firefox: https://jsfiddle.net/jib1/p1wjse6v/ - respectively:
Are data urls secure context?
No go in Chrome & Firefox: https://jan-ivar.github.io/dummy/iframe_gum_sandbox_isolate.html
|
I don't think it's that straightforward for sandboxed iframes. It would be great if we could also get some consistency there. At the moment, Chrome:
Firefox allows no permission delegation to opaque origins ("null principals") and thus neither sandboxed iframes nor data: should work. After chatting with Anne and @jib I think we're generally in support of dropping this restriction on opaque origins. If we remember correctly it was there because we couldn't convey the permission to users ("unknown site would like access your camera"), but now with FP that feels fixed. So, I would like to look into opening up opaque origins to permission delegation, but it should be consistent. |
(As jib just pointed out above) |
(Data URLs are a secure context again as of recently, but this hasn't been updated everywhere yet.) |
data: URLs should have an opaque origin, which should be cross-origin to everything, including identical data: URLs. This, as far as I can tell, is analogous to the situation with sandboxed frames, and I think that they should be treated identically.
That means that you should be able to write
and allow the
camera
feature in that frame, exactly as if it were a sandboxed frame.This is what Chrome does, and I think is what the feature policy spec says but doesn't match the WPT here. If that's not the case, should we change the spec, or are the tests correct?
@domenic @annevk @bakulf
The text was updated successfully, but these errors were encountered: