Intent to Prototype and Ship: Add schemes for decentralized web protocols to the safelist of registerProtocolHandler

473 views
Skip to first unread message

Frédéric Wang

unread,
Apr 24, 2020, 4:00:38 AM4/24/20
to blink-dev
Contact emails

fw...@igalia.com

Explainer

registerProtoclHandler() is a method that “allows Web sites to register themselves as possible handlers for particular schemes” (from whatwg/html). The set of schemes that can be associated with custom handlers is restricted to a safelist and schemes that begin with web+ (whatwg/html#safelisted-schemes).

The current list of Blink’s whitelisted schemes (as of April 24, 2020) can be found here. It is exactly the same as the one in the HTML specification: bitcoin, geo, im, irc, ircs, magnet, mailto, mms, news, nntp, openpgp4fpr, sip, sms, smsto, ssh, tel, urn, webcal, wtai, xmpp.

This intent to ship is about adding the following schemes for decentralized web to the safelist: dat, dweb, ipfs, ipns, ssb.

Spec

Spec for registerProtocolHandler is in the HTML specification and extension is proposed on this issue. Note that no functional implementation change is proposed here other than the extension of the set of customizable schemes.

The spec explicitly encourages expanding the scheme safelist: "This list can be changed. If there are schemes that ought to be added, please send feedback." As such, developers have made the above proposals, which we're now acting on.

Skipping TAG review since this proposal is for custom schemes whose functionality is left up to applications.

Summary

Extend list of URL schemes that can be overridden via registerProtocolHandler() with the following schemes for decentralized web: dat, dweb, ipfs, ipns, ssb.

Motivation

Extending the list to include decentralized web protocols allows resolution of links to generic entities independently of the website or gateway that’s providing access to it.

For example, ipfs:QmT9qk3CRYbFDWpDFY could be a URL for a resource on IPFS (Note.: The example URL is not a valid IPFS URL). The process of resolving the URL to bytes may be performed via a local IPFS gateway at http://localhost:8080/ipfs#ipfs:QmT9qk3CRYbFDWpDFY or via a web gateway at https://ipfs.gateway.example/ipfs#ipfs:QmT9qk3CRYbFDWpDFY.

If ipfs was a whitelisted scheme, then either http://localhost:8080 or https://ipfs.gateway.example/ipfs could request permission to handle ipfs: links. Furthermore, anyone can publish links to resources under IPFS using ipfs: links regardless of the user’s choice of gateway. Currently there’s no portable mechanism to make navigations to ipfs: URLs work without friction.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes .

Debuggability

No additional considerations beyond those for registerProtocolHandler.

Risks

Interoperability and Compatibility

Adding support for more custom schemes does not pose a compatibility risk with existing pages since none should depend on being able to register handlers for hitherto disallowed schemes.

Blink and Gecko are the only engines that currently implement registerProtocolHandler. They gate registration of scheme handlers by web pages as per spec. In addition, Firefox allows WebExtensions to register handlers for distributed web schemes (see Firefox’s WebExtensions protocol_handler safelist here).

See the original intent and WHATWG proposal for discussion of risks and alternatives. The ones proposed thread seems to be uncontroversial, are mature and have strong community support. This potential risk from the original thread is relevant:

Conflicts with native support. Popular browsers in the future may, and specialized browsers currently do, implement native support for some of the distributed web protocols. Where native support for a protocol exists, the corresponding scheme will need to be removed from the safelist for each respective browser, and eventually from the spec. We believe that native support for a protocol would not reduce functionality for users and hence such a change would not be disruptive.

Edge: public support

Firefox: public support

Safari: No signals (does not implement registerProtocolHandler), public support on extending the whitelist rather than switching to a blocklist

Web / Framework developers: Positive.

Please include links where possible. Examples include resolutions from relevant standards bodies (e.g. W3C Working Group), tracking bugs, or links to online conversations.

Ergonomics

No additional considerations beyond those for registerProtocolHandler.

Activation

No additional considerations beyond those for registerProtocolHandler. The HTML spec will be updated concurrently to reflect changes to the safelist.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Tests exist for registerProtocolHandler (here) which verify that all whitelisted schemes are overridable. This Chromium CL extends the test to cover the decentralized web protocols proposed here.

Entry on the feature dashboard

https://www.chromestatus.com/feature/4776602869170176


Dominic Farolino

unread,
Apr 24, 2020, 12:47:44 PM4/24/20
to Frédéric Wang, blink-dev
On Fri, Apr 24, 2020 at 2:00 AM Frédéric Wang <fw...@igalia.com> wrote:
Contact emails

fw...@igalia.com

Explainer

registerProtoclHandler() is a method that “allows Web sites to register themselves as possible handlers for particular schemes” (from whatwg/html). The set of schemes that can be associated with custom handlers is restricted to a safelist and schemes that begin with web+ (whatwg/html#safelisted-schemes).

The current list of Blink’s whitelisted schemes (as of April 24, 2020) can be found here. It is exactly the same as the one in the HTML specification: bitcoin, geo, im, irc, ircs, magnet, mailto, mms, news, nntp, openpgp4fpr, sip, sms, smsto, ssh, tel, urn, webcal, wtai, xmpp.

This intent to ship is about adding the following schemes for decentralized web to the safelist: dat, dweb, ipfs, ipns, ssb.

Spec

Spec for registerProtocolHandler is in the HTML specification and extension is proposed on this issue. Note that no functional implementation change is proposed here other than the extension of the set of

"in the HTML specification" is not a link. 
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ca5baf37-3a4a-fd0e-3143-dd98a0e4f1cc%40igalia.com.

Frédéric Wang

unread,
Apr 24, 2020, 1:17:46 PM4/24/20
to blin...@chromium.org
On 24/04/2020 18:47, Dominic Farolino wrote:

of the set of

"in the HTML specification" is not a link. 

Thank you, this was meant to be the same link as at the beginning: https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers


-- 
Frédéric Wang

Mounir Lamouri

unread,
Apr 24, 2020, 1:52:25 PM4/24/20
to Frédéric Wang, blink-dev
Wouldn't Firefox's position be more accurate as "Shipped"?

-- Mounir

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

L. David Baron

unread,
Apr 26, 2020, 1:00:17 AM4/26/20
to Mounir Lamouri, Frédéric Wang, blink-dev
On Friday 2020-04-24 10:51 -0700, 'Mounir Lamouri' via blink-dev wrote:
> Wouldn't Firefox's position be more accurate as "Shipped"?

Not based on the current code, which is:
https://searchfox.org/mozilla-central/rev/5470b66539234e52e76bc2176d9bec12325fc555/dom/base/Navigator.cpp#843-849
and matches the spec without this addition.

(It's also not clear to me what "public support" the statement of
the position is currently pointing to, but if you want an official
position you can ask for one at
https://github.com/mozilla/standards-positions/ .)

-David
> > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3bc903ac-ce11-fb9c-518d-ab7d55e31491%40igalia.com?utm_medium=email&utm_source=footer>
> > .
> >
>
> --
> You received this message because you are subscribed to the Google Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2B-LeH9h-U68J5paO%3DMT_Z8fvMqn6a5rpBDri_Wd8ZtZpd6L9Q%40mail.gmail.com.

--
𝄞 L. David Baron https://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)

Frédéric Wang

unread,
Apr 27, 2020, 4:09:00 AM4/27/20
to blink-dev
On 26/04/2020 07:00, L. David Baron wrote:
> Not based on the current code, which is:
> https://searchfox.org/mozilla-central/rev/5470b66539234e52e76bc2176d9bec12325fc555/dom/base/Navigator.cpp#843-849
> and matches the spec without this addition.

David is right. I guess there is a confusion as in past discussion it
was mentioned that Mozilla uses a blacklist (this was changed in
https://bugzilla.mozilla.org/show_bug.cgi?id=1476035) and also Mozilla
already whitelisted the additions proposed here but only for web
extensions (https://bugzilla.mozilla.org/show_bug.cgi?id=1428446).

Implementing this is tracked by
https://bugzilla.mozilla.org/show_bug.cgi?id=1631446 but review and
intent-to emails are pending on the WHATWG discussion (*).

> (It's also not clear to me what "public support" the statement of
> the position is currently pointing to, but if you want an official
> position you can ask for one at
> https://github.com/mozilla/standards-positions/ .)

Sorry, I think I messed this up when I extracted it from the original
proposal (
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/29sFh4tTdcs/K4XroilVBAAJ
). It seems in the past Mozilla was supportive of
distributed/decentralized protocols, they whitelisted the protocols in
web extensions, worked on libdweb ( https://github.com/mozilla/libdweb )
and communicated on dweb (you can find misc articles on Hacks Mozilla).I
don't have any public statement for this particular proposal, though.
Anyway, as I said this is currently pending on the WHATWG discussion (*).

(*) https://github.com/whatwg/html/pull/5482

--
Frédéric Wang


Frédéric Wang

unread,
May 16, 2020, 4:07:52 AM5/16/20
to blin...@chromium.org
Hi,

I've been coordinating with the dweb community and the updated proposal
for decentralized technologies is to add:

ethereum
dat
dweb
ipfs
ipns
ssb
cabal
hyper

All of these schemes are now documented on IANA's page for URI schemes (
https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml )

I also opened a Mozilla's standards-position issue (
https://github.com/mozilla/standards-positions/issues/339 )

--
Frédéric Wang

dani...@gmail.com

unread,
May 20, 2020, 4:17:35 PM5/20/20
to blink-dev
Can we please ensure that did: is included here, given it is an actual standards track spec underway in a W3C Working Group? --> https://w3c.github.io/did-core/

Mike West

unread,
Jun 4, 2020, 1:39:37 PM6/4/20
to Frédéric Wang, blink-dev, dani...@gmail.com
LGTM1 (including the suggestion to support `did:`, as it seems in-line with the rest of this change).

I think it's reasonable to extend the safelist to include these distributed schemes. I agree with the suggestion in Mozilla's standards-position discussion that there's some risk of the non-decentralized web's origin model conflicting with the origins we'd like to assign to decentralized URLs in an ideal world. This is important to keep in mind, but there's something of a chicken and egg problem in evaluating the harm to users. If these schemes become widely used, then it's likely that a given provider might inadvertently allow distinct "origins" to access each others' data. But, if the protocols are widely used enough for this to be actually dangerous, then we should probably support them more directly in the browser, either by enforcing origin separation when handling the protocol, or by natively supporting the protocol with a reasonable origin model.

Let's err on the side of allowing sites to handle these protocols, which will give us some insight into whether they're viable enough for us to put more effort into mitigating the potential future risks.

-mike

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Yoav Weiss

unread,
Jun 4, 2020, 3:05:53 PM6/4/20
to Mike West, Frédéric Wang, blink-dev, dani...@gmail.com

sligh...@chromium.org

unread,
Jun 4, 2020, 3:08:54 PM6/4/20
to blink-dev, mk...@chromium.org, fw...@igalia.com, dani...@gmail.com
LGTM3.

Thanks for outlining the risks here, Mike.

Regards
LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Frédéric Wang

unread,
Aug 3, 2020, 9:23:09 AM8/3/20
to blin...@chromium.org

Hi,

So an update on this:

* We have test and spec changes PRs pending on 2 implementer support. Other requests like IANA registration have been addressed.

* We have 3 LGTM in chromium and a CL pending.

* WebKit does not support this registerProtocolHandler and in the old webkit-dev discussion around registerProtocolHandler, it seems Apple's feedback was to follow a conservative approach in general (trying to be as restrictive as possible e.g. keeping a whitelist).

* Mozilla hasn't replied since mid may. They told me they try to do new review request in a 2 weeks to 2 months range but David Baron's reply https://github.com/mozilla/standards-positions/issues/339#issuecomment-644289267 suggests it could take more time.

* Mozilla supports some of these extra schemes (e.g. ipfs) for Web Extensions only. I've tried to temporarily add them for Chrome extension contexts in https://chromium-review.googlesource.com/c/chromium/src/+/2287304 but during review Mike suggested we should just implement them now that we have the 3 LGTMs.

Given Mike's "chicken and egg" argument, I'll just go ahead implementing it under a preference so we can start experiencing this. Hopefully doing this and and other security/interop improvements of registerProtocolHandler will help to get a reply from Mozilla and maybe for the long-term help with webkit discussion.

If you think this is not a good idea and we should wait support from Mozilla, please let me know.

-- 
Frédéric Wang

Tom Jones

unread,
Aug 3, 2020, 2:20:02 PM8/3/20
to Mike West, Frédéric Wang, blink-dev, dani...@gmail.com
I am confused:
1> the did is a url - where would conflict arise?
2> if the user does not trust their money with the protocol, it is doomed, Security must be top of mind and communicated to the user.
Peace ..tom


Frédéric Wang

unread,
Sep 7, 2020, 8:02:28 AM9/7/20
to Mark Nadal, blink-dev
On 05/09/2020 02:36, Mark Nadal wrote:
> Can I ask why webtorrent and gun were ignored but ipfs/dat/ssb/etc.
> listed for inclusion? Mine has 10M ~ 30M monthly users and our
> decentralized network handles 10K+ users a second. It is used by
> Internet Archive (https://dweb.archive.org/ ipfs broken there but both
> webtorrent and gun are working), sponsored by Mozilla, and used by
> many others -  https://github.com/amark/gun .
>
Sure, there were a lot of concerns and discussions on the original
intent (
https://groups.google.com/a/chromium.org/forum/?pli=1#!msg/blink-dev/29sFh4tTdcs/K4XroilVBAAJ
) so I tried to unblock stuff as follows:

- I tried and found a consensus on
https://github.com/whatwg/html/issues/3998 between Mozilla and Google ;
preference was to extend the safelist rather than moving to a blocklist.

- I went over the list of the original intent as well as new ones
reported at WHATWG https://github.com/whatwg/html ; checking the status
and extracting the non-controversial ones.

- My work is sponsored by Protocol Labs so I focused on their requests
and those from their friends around decentralized schemes.

- I registered some protocols at IANA that were missing, as requested by
Mozilla.

- I asked Microsoft if they need more for their current work on web
apps, but none were requested so far.

- I sent patches, position request & intent to
Mozilla/Chromium/WebKit/WHATWG/WPT ; Chromium API owners approved the
request and "did" was added in the list during the process ; WebKit does
not seem to have big interest for now besides maybe "mailto" ; Mozilla's
request has been pending for several months so whether they support this
is still an open question.

- I was suggested to land the Chromium patch for now until this get
resolved, which I did.

So unless I missed something, I haven't found any mention of your
protocols nor did any of your supporter (e.g. Mozilla) request them.

> How can we be included? Thanks.

Basically following the same procedure as for other protocols. Currently
I'm working on other tasks, but once we get a reply from Mozilla I plan
to finish the work on the WHATWG/WPT/Mozilla side too. I don't think it
makes much sense to go back to this until we get a reply.

We can of course still include your protocols and others that were not
in this intent. Since you say your protocols are sponsored by Mozilla, I
suggest you add your requests to
https://github.com/mozilla/standards-positions/issues/339 and talk to
your contacts so that they can unblock this work. Other than that, you
would need to open a request at WHATWG too, register your protocols at
IANA if not already done, and someone would have to write
implementation/WPT patches once a consensus is found.

Hope that helps,

--
Frédéric Wang

Mark Nadal

unread,
Sep 8, 2020, 11:34:09 AM9/8/20
to blink-dev, fw...@igalia.com
Can I ask why webtorrent and gun were ignored but ipfs/dat/ssb/etc. listed for inclusion? Mine has 10M ~ 30M monthly users and our decentralized network handles 10K+ users a second. It is used by Internet Archive (https://dweb.archive.org/ ipfs broken there but both webtorrent and gun are working), sponsored by Mozilla, and used by many others -  https://github.com/amark/gun .

How can we be included? Thanks.
Reply all
Reply to author
Forward
0 new messages