Skip to content

Restrict use of registerProtocolHandler to secure contexts #4017

Closed

Description

@asankah

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

cc @domenic @annevk @mgiuca

Activity

  1. domenic commented on Sep 7, 2018

    @domenic
    Member

    This would be great, PR/tests appreciated.

  2. asankah commented on Sep 7, 2018

    @asankah
    ContributorAuthor

    Cool. I'll follow up with PRs.

    cc @mikewest

  3. added
    impacts documentationUsed by documentation communities, such as MDN, to track changes that impact documentation
    on Sep 11, 2018
  4. chrisdavidmills commented on Oct 31, 2018

    @chrisdavidmills
  5. domenic commented on Nov 4, 2019

    @domenic
    Member

    Ping @asankah on a spec/tests update here.

  6. ericlaw1979 commented on Nov 4, 2019

    @ericlaw1979
    Contributor

    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.

  7. asankah commented on Nov 4, 2019

    @asankah
    ContributorAuthor

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

  8. annevk commented on Nov 12, 2019

    @annevk
    Member

    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.

  9. mikewest commented on Nov 12, 2019

    @mikewest
    Member

    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?

  10. ericlaw1979 commented on Nov 12, 2019

    @ericlaw1979
    Contributor

    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

    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)
  11. annevk commented on Nov 12, 2019

    @annevk
    Member

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

  12. added a commit that references this issue on May 18, 2025
    6772a03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    impacts documentationUsed by documentation communities, such as MDN, to track changes that impact documentationnormative changesecurity/privacyThere are security or privacy implications

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions