Safelisting DWeb Protocols

[lidel]

Summary

We want dweb protocols to be available without web+ prefix in contexts such as:

• navigator.registerProtocolHandler
• WebExtensions (manifest.json/protocol_handlers, if vendor supports it)

Namely: "ssb", "dat", "ipfs", "ipns", "dweb" (comment if something else should be added to the list)

Motivation

Safelisting protocols in above contexts is an easy change and it makes it possible for community to start using non-HTTP addresses with HTTP-based gateways/readers even before native protocol handler API is introduced.

Additionally, if we have at least two vendors implementing proposed change we would have a solid case for adding them as safelisted-scheme in HTML Spec.

Tasks

• Update HTML Spec to include protocols on "safelist"
  • upstream issue: Safelist protocol handlers for DWeb whatwg/html#3935
• navigator.registerProtocolHandler allows handler without web+ prefix
  • Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=1631446 and Add new safelisted schemes for registerProtocolHandler() mozilla/standards-positions#339
  • Chromium: https://crbug.com/651311#c10 + intent-to-implement
  • ? (to add item here create issue in vendor's tracker and comment below)
• WebExtension is able to register navigator.registerProtocolHandler-like handler without user interaction (see Safelisting DWeb Protocols #23 (comment) for more context)
  • Firefox (via manifest.json/protocol_handlers)
  • Chrome (not supported atm, filled bug: https://crbug.com/883274)

Resources

• List of safelisted-schemes in HTML Spec
• Firefox 59 whitelists protocol handlers for work on decentralization technologies (webextensions only)
• [whatwg] Adding "ipfs" to the safelisted schemes by @mathiasrw
  • stalled due to lack of vendors implementing change for navigator.registerProtocolHandler

[lidel]

@KenjiBaheux regarding "registering whitelisted dweb protocols": yes, safelisting dweb protocols in Chrome would be a valuable step in the right direction!

With current Firefox Stable (61) the "user installs extension Foo and is able to open content from foo:// URLs" is possible thanks to:

• Whitelisting dweb protocols so we can use them without "web+" prefix
  • Firefox 59 whitelisted dweb protocols in webextension context, which means they don't need to be prefixed with "web+" and are actually usable in the wild.
    This should also be safe/easy to ship, and it would mean we have two vendors on board to push discussions like this one bit further (for all of dweb protocols).
• Simplified handler that is only a redirect to an HTTP page
  • Firefox 54 implemented redirect-based handler that is specified via extension manifest.
    • This is not a native handler, it is just a redirect to a HTTP page, but it makes links to non-HTTP protocol work in browser, solving basic UX of being able to access content.
    • IIUC it is basically a thin wrapper on top of navigator.registerProtocolHandler so it should be safe to implement the same in Chrome.

Right now Chrome does not allow webextensions to automatically register basic redirect handler nor manually register dweb protocol without web+ prefix.

Would be greeat if Chrome could follow what was done in Firefox.
Having that we could start adopting URI schemes other than https:// and be sure users are able to at least open them with WebExtensions or via HTTP gateways

[KenjiBaheux]

We are tracking the whitelisting of dweb protocols via navigator.registerProtocolHandler in crbug.com/651311.

• Still being discussed internally. But there is support for the dweb protocols as long as they don't have human readable parts which could be a source of confusion for unsuspecting users.
• We would probably do this in general (i.e. not limited to a webextension context). In that case, would we still need the "simplified handler ..." item noted above?

[lidel]

@KenjiBaheux Thanks for the update!

Without "simplified handler" the UX for registering support for a new protocol in URLs is okay for websites, but still quite bad on webextension side. Take a look at a simplified flow:

1. user installs extension to support protocol foo://, but it is not enough to open foo://bar
2. user needs to manually visit an arbitrary website (extension can open it on install, but people hate popups and close them before they load)
3. website calls navigator.registerProtocolHandler to register itself as redirect-based handler for the foo:// protocol
4. browser displays permission prompt
5. user needs to manually accept website for handling URLs with new protocol
6. finally, if all the above went ok, user can open foo://bar

This means user has to not only install browser extension but also go over all those steps, otherwise there will be no support for new protocol. Still, even navigator.registerProtocolHandler alone is much better than nothing :)

---

With the very thin sugar-coating provided by webextension's manifest.json/protocol_handlers UX is much better:

The protocol_handler API lets you easily map protocols to actions in your extension. For example: we use irccloud at Mozilla, so we can map ircs:// links to irccloud by adding this into an extension:

"protocol_handlers": [
  {
    "protocol": "ircs",
    "name": "IRC Mozilla Extension",
    "uriTemplate": "https://irccloud.mozilla.com/#!/%s"
  }
]

When a user clicks on an IRC link, it shows the application selector with the IRC Mozilla Extension visible:

[lidel]

In an effort to get this off the ground opened issue for changing WHATWG HTML Spec to include DWeb protocols on the "safelist": whatwg/html#3935

On the vendor side "safelist" support looks like this:

• Firefox already supports what we need, because it does not require web+ prefix for handlers registered via navigator.registerProtocolHandler. They have a blacklist instead.
• Chromium refuses to register handler without web+ prefix for protocols that are not on the HTML safelist. I posted short update in crbug.com/651311#c10 in effort to unblock things on the Chromium side.
  • We are new to the process, so any guidance/help with moving this forward is highly appreciated!
• Brave will use custom build of Chromium: they could override safelisting rules as a part of the build, but it makes more sense to try to solve it upstream in Chromium first.

[KenjiBaheux]

We just posted our public intent to implement and ship additional safelisted protocols.

I don't expect any major push back but feel free to voice your support and share details about what this enables for you and end-users.

[lidel]

@KenjiBaheux I filled https://crbug.com/883274 (Extensions API should implement manifest.json/protocol_handlers) to address UX issues from #23 (comment).
It is an additional task on top of safelisting DWeb protocols, which is tracked in https://crbug.com/651311.

[agentofuser]

It would be great to have git:// whitelisted as well.

[lidel]

@agentofuser git:// and other VCS are tracked in whatwg/html#1829 :)

[olizilla]

Tested this and it seems that Firefox 88 does not currently suppport navigator.registerProtocolHandler for ipfs and other dweb protocols, as per mozilla/standards-positions#339

and the whatwg/html spec change is waiting on a positive response from Mozilla

Just an update on this, the current list is

cabal
dat
did
dweb
ethereum
hyper
ipfs
ipns
ssb

• spec, WPT, mozilla and chromium patches have been updated accordingly.
• Chromium API owners approved this change
• still waiting feedback from Mozilla on Add new safelisted schemes for registerProtocolHandler() mozilla/standards-positions#339

– whatwg/html#5482 (comment)

[fred-wang]

Yes, and Mozilla's bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1631446