Html: Restrict use of `registerProtocolHandler` to secure contexts

[asankah]

This is already the case in Firefox since 60. Chrome will likely follow suit.

cc @domenic @annevk @mgiuca

[domenic]

This would be great, PR/tests appreciated.

[asankah]

Cool. I'll follow up with PRs.

cc @mikewest

[chrisdavidmills]

Already updated on the documentation: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler

[domenic]

Ping @asankah on a spec/tests update here.

[ericlaw1979]

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]

Yay! @ericlaw1979 Are you also doing a spec update?

[annevk]

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]

I'd propose that we allow registerProtocolHandler() from "first-party" frames as well

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]

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 (https://github.com/whatwg/html/pull/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

1. Learn how to express that in spec-ese
2. 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)

[annevk]

@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.)