Skip to content
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

Open
clelland opened this issue May 4, 2020 · 8 comments
Open

Policies in data: urls #374

clelland opened this issue May 4, 2020 · 8 comments

Comments

@clelland
Copy link
Collaborator

clelland commented May 4, 2020

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

<iframe src="data:..." allow="camera 'src'">

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

@annevk
Copy link
Member

annevk commented May 4, 2020

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 permission-thingie 'src' that would lead to a non-match, which might be unexpected?

cc @johannhof

@clelland
Copy link
Collaborator Author

clelland commented May 4, 2020

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.

@annevk
Copy link
Member

annevk commented May 4, 2020

It's mostly that maybe we shouldn't consider the origin contained in src, but instead the origin of the first non-initial about:blank document. That might work for all scenarios.

@clelland
Copy link
Collaborator Author

clelland commented May 4, 2020

That would cover everything except HTTP-level redirects with tuple origins, I expect.

@jan-ivar
Copy link
Member

jan-ivar commented May 4, 2020

This is what Chrome does

It's not working for me in Chrome or Firefox: https://jsfiddle.net/jib1/p1wjse6v/ - respectively:

TypeError: Cannot read property 'getUserMedia' of undefined
TypeError: can't access property "getUserMedia", navigator.mediaDevices is undefined

Are data urls secure context?

analogous to the situation with sandboxed frames

No go in Chrome & Firefox: https://jan-ivar.github.io/dummy/iframe_gum_sandbox_isolate.html

SecurityError: Invalid security origin
NotAllowedError: The request is not allowed by the user agent or the platform in the current context.

@johannhof
Copy link
Member

This, as far as I can tell, is analogous to the situation with sandboxed frames

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:

  • allows geolocation via FP/permission delegation in sandboxed iframes
  • does not allow camera or microphone in sandboxed iframes

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.

@johannhof
Copy link
Member

(As jib just pointed out above)

@annevk
Copy link
Member

annevk commented May 5, 2020

(Data URLs are a secure context again as of recently, but this hasn't been updated everywhere yet.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants