You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Restrict use of registerProtocolHandler to secure contexts #4017
I'd propose that we allow registerProtocolHandler() from "first-party" frames as well, i.e., as long as the global's origin matches the top-level origin it should be fair game. This would make it align with permission delegation (Feature Policy), though I don't think we should offer the ability to delegate as that makes little sense.
Yeah, sorry, I had to learn a bunch of stuff, having never contributed to HTML before.
My thinking was that I'd start with the easy one, requiring "SecureContext" to call the API (#5080)
After I learned how to do things with that, I'd then propose a second patch that reflects our agreement about the subframes question. My current Chrome PR requires that the call be from the top-level context (https://chromium-review.googlesource.com/c/chromium/src/+/1892213).
I can adjust that to allow same-origin frames, but I'll need to
Learn how to express that in spec-ese
Understand whether this is literally just a same-origin check or if there are other considerations (e.g. ancestor-origins-like whereby intervening cross-origin ancestor frames are disqualifying)
@ericlaw1979 it'll be a same-origin comparison with the concept that's being added in #4966 (top-level origin). And if A is nested in B is nested in top-level A both As will be same origin with that concept. (This is a little different from the equivalent situation in redirect chains (well, sometimes), but as both As have direct script access to each other being strict doesn't really help.)
Activity
domenic commentedon Sep 7, 2018
This would be great, PR/tests appreciated.
asankah commentedon Sep 7, 2018
Cool. I'll follow up with PRs.
cc @mikewest
chrisdavidmills commentedon Oct 31, 2018
Already updated on the documentation: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler
domenic commentedon Nov 4, 2019
Ping @asankah on a spec/tests update here.
ericlaw1979 commentedon Nov 4, 2019
FWIW, I have a proposal for the Chromium change out for review: https://chromium-review.googlesource.com/c/chromium/src/+/1892213. Beyond adding the secure context restriction, it requires a top-level browsing context.
asankah commentedon Nov 4, 2019
Yay! @ericlaw1979 Are you also doing a spec update?
annevk commentedon Nov 12, 2019
I'd propose that we allow
registerProtocolHandler()from "first-party" frames as well, i.e., as long as the global's origin matches the top-level origin it should be fair game. This would make it align with permission delegation (Feature Policy), though I don't think we should offer the ability to delegate as that makes little sense.mikewest commentedon Nov 12, 2019
This is very much in line with the patch @ericlaw1979 put up for review. I think he was planning on sending out a PR against HTML?
ericlaw1979 commentedon Nov 12, 2019
Yeah, sorry, I had to learn a bunch of stuff, having never contributed to HTML before.
My thinking was that I'd start with the easy one, requiring "SecureContext" to call the API (#5080)
After I learned how to do things with that, I'd then propose a second patch that reflects our agreement about the subframes question. My current Chrome PR requires that the call be from the top-level context (https://chromium-review.googlesource.com/c/chromium/src/+/1892213).
I can adjust that to allow same-origin frames, but I'll need to
annevk commentedon Nov 12, 2019
@ericlaw1979 it'll be a same-origin comparison with the concept that's being added in #4966 (top-level origin). And if A is nested in B is nested in top-level A both As will be same origin with that concept. (This is a little different from the equivalent situation in redirect chains (well, sometimes), but as both As have direct script access to each other being strict doesn't really help.)
Restrict (un)registerProtocolHandler to secure contexts