Are you saying browsers already include these on the safelist, or is this a proposal and you're hoping to get implementer interest?

This is a proposal. I intend to submit patches to browsers in parallel.

This seemed like a change for which the implementation was straightforward enough (extending an existing safelist) that submitting the standards patch to kick off discussion seemed appropriate.

That is certainly fair. Please keep this issue informed about any patches/bugs against browsers.

This may also be a good place to put your reasoning, if browsers ask why adding these is important. E.g. what new applications this allows you to build, and why this deserves the same status as the existing safelisted schemes, and so on.

(Updated the list to include one missing scheme.)

Chromium bug at https://bugs.chromium.org/p/chromium/issues/detail?id=651311 , patch at https://codereview.chromium.org/2378773003/ .

Firefox, as far as I can tell, doesn't use a safelist for registerProtocolHandler; it uses a denylist instead. So Firefox already supports all these schemes.

+1 from Chromium. Will follow up on Chromium issue.

@joshtriplett, are you still interested in this? If so, could you sign the Participant Agreement? It's a new requirement since you first submitted this PR.

This has been discussed on a blink-dev thread.

Pasting my relevant comments:

I think it "smells" a bit when we start adding specific companies or services' names to web specs. Most of the existing ones are generic, but it's a bit irksome that we have "bitcoin" on there, for example, being just one cryptocurrency scheme.

• bzr, cvs, darcs, git, hg, svn: A little "smelly" that we would favour a specific set of revision control systems, but at least these represent distinct technologies, not specific companies or sites (so I'm not fully opposed to this).
• lp: This URL scheme is (as far as I'm aware) used by the Bazaar revision control system specifically as a short-hand for repos hosted on the https://launchpad.net website. It doesn't feel generic enough that it should be exposed in a web standard.

My preference would be to switch from a whitelist to a blacklist, which would be significantly smaller than an ever-expanding list of all protocols that anybody has ever wanted to expose on the web. #3998

@mgiuca Personally, I'm entirely in favor of switching to a blocklist, which AFAICT is what Firefox does as well.

In the meantime...I feel like this is a list of unique version control system protocols, not a list of specific products; for instance, there are a few pieces of software out there that speak the bzr or hg or git protocols, not just the original piece of software.

As for lp and bzr+lp, the only reason I'm proposing them is that bzr has native support for those that ships in the stock version, not via custom configuration but as a built-in part of the standard client, and because of that people regularly pass around such URLs and just hand them to bzr clone and similar tools, without further explanation or alternates. People expect those URLs to Just Work.

As for lp and bzr+lp, the only reason I'm proposing them is that bzr has native support for those that ships in the stock version, not via custom configuration but as a built-in part of the standard client, and because of that people regularly pass around such URLs and just hand them to bzr clone and similar tools, without further explanation or alternates. People expect those URLs to Just Work.

Yeah, I'm aware of that (it's tough to find people who know Bzr these days, but I was 100% in the Bzr camp back in the day!). It's a fair point, this is part of the set of URLs recognised by Bzr itself. On the other hand, as far as I know, websites don't typically include direct links to "lp:" URLs (or, rather, any raw revision control URLs) since they pretty much don't work right now. While those URLs are useful to paste into revision control clients, they aren't seen in <a href>s on the web. So it's not unrealistic to expect that if, say, we added "bzr" to the whitelist but not "lp", then websites would just expand "lp:" links to the full "bzr:" format.

In other words, we don't have to accept every possible URL scheme accepted by the client itself, in order for this to be useful.

Having said that, I'd be in favour of switching to a blacklist as well. It would remove all of these questions. If Firefox is, as you say, already open-ended, then it should be much less of an issue for Chrome and other browsers to migrate over (note: I'm kinda-sorta-responsible for registerProtocolHandler on Chrome so I can help here, but it looks like @asankah has it covered). Please discuss on #3998.

A blocklist would be tricky if we ever need a new scheme for some web platform feature, though I suppose we could reserve a prefix of sorts.

I'm not sure it's that bad if an allowed scheme becomes disallowed.

RPH won't generally be a core function of a website (for one thing, many browsers don't even support this feature). Generally they're just a nice-to-have feature. A future change to add a new scheme to the blocklist will disrupt handling of certain schemes, but not stop the user from getting to that resource through some other means. Same applies to user-agent-specific blocked schemes. Let's say some site registers to handle "chrome:" URLs for some reason, and it works in Firefox but not Chrome, that isn't a very big deal.

There may be a list of schemes we want to guarantee never get blocked by any browser (e.g. "mailto"). Perhaps just the list of things we already have. So we could say:

User agents MUST NOT allow sites to register the following schemes: (blocklist): "https", "ftp", etc.

User agents MUST allow sites to register the following schemes: (whitelist): "mailto", "bitcoin", etc. And any scheme starting with "web+".

User agents SHOULD allow sites to register any other scheme, but MAY disallow any specific scheme.

If so, could you sign the Participant Agreement? It's a new requirement since you first submitted this PR.

@joshtriplett, I signed whatwg/participant-data@2c4a895. @domenic I expect that to satisfy the requirement.

Great, one other thing that'd be good here is tests.

Awesome, thanks @anssiko!

Do we know how to test protocol handlers? And, how's our safelist-vs.-blocklist discussion coming? If I recall I found @mgiuca's positions fairly convincing, but IIRC @annevk had some concerns about how blocklists are only easier for browsers with larger market share, and I'm not sure those were addressed.

Do we know how to test protocol handlers?

We have some basic tests in wpt, and I just imported more chromium tests to wpt in PR web-platform-tests/wpt#14294.

web-platform-tests/wpt#14294 was merged. Anything else blocking this PR we could help with?

@anssiko is there a bug for Safari?

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1514203 to keep track of switching Firefox to a safelist-based approach. Firefox uses a safelist.

@annevk I’m not aware of a Safari bug. @joshtriplett submitted the Chromium bug https://bugs.chromium.org/p/chromium/issues/detail?id=651311 quite a while ago, and I believe is waiting for the spec patch to land before advancing to other browsers.

What I recall is that @asankah worked to advance this in Blink, but ran into disagreements with other Blink folks (I remember @mgiuca, but there may have been others) and the project stalled :-/.

I'm still interested in seeing this move forward. Is there anything that would help unstick this?

The live VCS landscape has changed in the ~8 years since I originally submitted this, and I'd be happy to prune back the list substantially if that would make it easier to accept.

It looks like, in #3998 , there's a proposal to switch to a blocklist instead, which would be even better. What would it take to move that proposal forwards?