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
Contact emailsExplainer
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
--
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.
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
--
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/3bc903ac-ce11-fb9c-518d-ab7d55e31491%40igalia.com.
--
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/6083e318-8105-43c8-9caa-45df099f63a9%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdPz%2B1ZUJCtLrfrbR%3D1c46GcNY2Jr3Y6%2Bj2Go8XHpD9Vw%40mail.gmail.com.
LGTM2
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6083e318-8105-43c8-9caa-45df099f63a9%40chromium.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.
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
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdPz%2B1ZUJCtLrfrbR%3D1c46GcNY2Jr3Y6%2Bj2Go8XHpD9Vw%40mail.gmail.com.