Patch submitted as https://codereview.chromium.org/2378773003/

As per the comment #1, requesting reviewers for an update.

Marking it as untriaged.

Thanks,

Removing "Internals>Network" component since the net stack doesn't handle these custom schemas.

You are putting the cart before the horse.  

You can't just unilaterally make arbitrary changes to standardized web APIs. This will break browser compatibility.

The first thing you need to do is to get browser vendors to agree to this change by proposing a change to the HTML specification.  The specification in question is here: https://html.spec.whatwg.org/multipage/webappapis.html#dom-navigator-registerprotocolhandler

To request a change, you must submit an issue against the specification on the github repository located here: https://github.com/whatwg/html/issues

Then, if you chose to do so yourself, you can submit a change to spec by following the guidelines here: https://github.com/whatwg/html/blob/master/CONTRIBUTING.md

Once that is done, because this is a web-facing feature, you need to take it through the launch process described here: http://www.chromium.org/blink#launch-process

I know this seems like a lot of red tape for such a small code change, but it is really important to do things right when we change API behaviors to avoid breaking the Web.

I've already posted a proposed change to the HTML standard, in the issue linked from the top of this bug: https://github.com/whatwg/html/pull/1829 .  That issue is awaiting confirmation of corresponding implementations in browsers.

I've also confirmed that Firefox supports these protocol schemes (because it uses a blacklist rather than a whitelist).

I'll go ahead and send an Intent to Implement and Ship to chromium-dev.  Since this doesn't add any new API entry points, just a few more entries in an existing whitelist of acceptable protocols, an "Implement and Ship" without a feature-flag seems appropriate.

I think this is more of a feature request, and it probably applies to all the platforms we control, right?

My security thought is that the permission prompt is sufficient to stop large-scale/non-targeted phishing or other confusion/social engineering attacks, in part because it fails safe (not allowing the site to register as a handler if the person ignores or closes the prompt). I would therefore be OK with landing (some form of) this patch. There's been a request to add other protocols, too, like for decentralized web.

Other people, especially from Secure UX team, may have other, better ideas.

palmer: This issue (and the whatwg issue to change the spec) has been dormant since October 2016, are we still considering this change? I couldn't find the intent to implement and ship discussion.

FWIW I also think the permission is sufficient to prevent confusion, but I'd be happier to see the spec change accepted before this lands into Chrome.

I'd also support adding these schemes.

For distributed web, is there already a PR for the schemes? If not, folks who plan on using the schemes should propose which schemes they need.

Issue with DWeb protocols is at https://github.com/whatwg/html/issues/3935 
and PR with change to HTML spec is at https://github.com/whatwg/html/pull/3936

I feel we really want to avoid situation where WHATWG waits for vendors, and vendors wait for WHATWG, like it happened with version control systems.
There seems to be a will to do do the change on both sides, at least when it comes to DWeb protocols.

What would be next step?  How can we provide tangible signal to WHATWG there is real will to do this?
Could someone more familiar with the launch process (http://www.chromium.org/blink#launch-process) help us to take DWeb this through it?

Also, is it okay to track version control system and decentralized protocols under one issue here, or is it better if I create a separate issue for DWeb part and move discussion there?

On Wed, Aug 15, 2018 at 02:40:44PM -0700, carlo… via monorail wrote:

I'm still interested in this, but back in 2016 when I first tried to
push it, I discovered / was informed by a couple of Chromium developers
that initiating the intent-to-implement process required filing
something in a system only accessible to Chromium developers, and I
didn't manage to find anyone willing to do so on my behalf.

I'd be happy to revive this, if someone with the appropriate permissions
would be willing to help with some of the process steps.

I'll start an intent-to-implement.

 Issue 879320  has been merged into this issue.