Contact emails
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 Google Chrome’s whitelisted schemes (as of August 27, 2018) can be found here. For your convenience, the current list is: bitcoin, geo, im, irc, ircs, magnet, mailto, mms, news, nntp, openpgp4fpr, sip, sms, smsto, ssh, tel, urn, webcal, wtai, and xmpp.
We are proposing the extension of the safe list with the following schemes:
dat, dweb, ipfs, ipns, ssb.
These are schemes that are used with distributed web protocols. Allowing custom handlers for these schemes aid experimentation of these protocols on Chrome.
bzr, bzr+ftp, bzr+lp, bzr+http, bzr+https, bzr+sftp, bzr+ssh, cvs, cvs+ext, cvs+pserver, cvs+ssh, darcs+http, darcs+https, darcs+ssh, git, git+http, git+https, git+ssh, hg, hg+http, hg+https, hg+ssh, hg+static-http, lp, svn, svn+http, svn+https, svn+ssh.
These schemes correspond to source control protocols along with variants for specifying subprotocols or underlying transports.
map, gmap, bingmap, location
Planned use in provider agnostic map URLs.
doi
Details on Digital Object Identifiers (DOI) can be found at https://doi.org.
Design doc/Spec
Spec for registerProtocolHandler is here. Note that no functional implementation change is proposed here other than the extension of the set of customizable schemes.
dat, dweb, ipfs, ipns, ssb based on this proposal.
bzr, bzr+ftp, bzr+lp, bzr+http, bzr+https, bzr+sftp, bzr+ssh, cvs, cvs+ext, cvs+pserver, cvs+ssh, darcs+http, darcs+https, darcs+ssh, git, git+http, git+https, git+ssh, hg, hg+http, hg+https, hg+ssh, hg+static-http, lp, svn, svn+http, svn+https, svn+ssh based on this proposal.
map, gmap, bingmap, location based on this proposal.
doi based on this proposal.
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().
Motivation
Extending the list to include version control, mapping, DOI, and 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.
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.
Google Chrome, Mozilla Firefox, and Opera are the only browsers that currently implement registerProtocolHandler. Chrome and Firefox 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).
The following risks exist:
User confusion with standard schemes. This could be an issue for the version control schemes that have protocol suffixes that are standard schemes, namely http and https.
While these URLs could be exposed to the user via mouse hover over links or displayed inline, the URLs themselves don’t appear in the omnibox. Google Chrome and Firefox both handle custom protocols as redirects. The URL shown in the address bar is the rewritten URL and not the custom scheme, thus mitigating the possibility of spoofing.
In the case of distributed web protocols, we are aware that the developer community desires custom URLs to be displayed in the omnibox, as well as being used for fetching subresources. Google Chrome has no current plans to implement this behavior.
Insufficient uptake of a scheme. While developers have expressed interest, metrics will ultimately tell us whether there’s sufficient uptake of each scheme. The incremental overhead for browser is trivial, though every bit counts.
Ossification of unspecified schemes. Some of the URL schemes being proposed for addition do not have a public specification, mature or otherwise. It is possible that one or more early adopters will prematurely define the URL scheme by their implementation. Whilst unfortunate, developers should assume this risk rather than the UAs.
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.
Scheme creep. “If scheme x is included, then why not scheme y?” might be a question we’ll soon need to deal with. This I2IS focuses only on schemes that were requested by developers.
Edge: No signals (does not implement registerProtocolHandler)
Firefox: Adding distributed web schemes (i.e. dat, dweb, ipfs, ipns, ssb) to safelist is being discussed here. Firefox allows WebExtensions to register themselves as handlers for these schemes since 59 (See compat table here and this issue). No signals for supporting other schemes.
Safari: No signals (does not implement registerProtocolHandler)
Web developers: All proposals are based on requests made by developers. For the distributed web schemes, see https://arewedistributedyet.com/.
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.
Debuggability
No additional considerations beyond those for registerProtocolHandler.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Is this feature fully tested by web-platform-tests?
Tests exist for registerProtocolHandler (here) which verify that all whitelisted schemes are overridable. Once approved, the schemes proposed here will be added to that list.
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/4776602869170176 (Distributed web schemes)
https://www.chromestatus.com/feature/5495924260339712 (Others)
Requesting approval to ship?
Yes
> Design doc/Spec
> Spec for registerProtocolHandler is here. Note that no functional
> implementation change is proposed here other than the extension of
> the set of customizable schemes.
I agree with the new schemes being added. However, it seems the
additions to the spec are new and still under review, and your proposal
adds too many new schemes at once.
Also, it is not clear what security issues will appear, if any, with
the new schemes. That said, in my opinion, it would be good if you
implement the schemes Firefox supports among all schemes you propose
first (dat, dweb, ipfs, ipns, ssb). Then consider if it's fine to
implement rest of things and ship it later.
GGyuyoung
GGyuyoung
--
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/1535960824.19932.1.camel%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEh9P1Oy9aYVQRunRhqUvOYbD%3DTpCtte3S8d43W_oxXcWQ%40mail.gmail.com.
Chrome for Android has the intent:// mechanism, I think.Internet Explorer and/or Edge have an API for launching the calls a callback if it does not work, I believe.So, mostly, no, probably.
☆PhistucKOn Mon, Sep 3, 2018 at 11:51 AM Yoav Weiss <yo...@yoav.ws> wrote:What's the feature detection story here?Is there a way for the developer to know if one of the new schemes is not supported in the current browser, and do some other action instead?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_%2B-PJbcsr%3Don1TOdunicpZL69ydu6x5GOmApSG3NF8sFw%40mail.gmail.com.
On Mon, Sep 3, 2018 at 11:03 PM PhistucK <phis...@gmail.com> wrote:Chrome for Android has the intent:// mechanism, I think.Internet Explorer and/or Edge have an API for launching the calls a callback if it does not work, I believe.So, mostly, no, probably.On desktop OSes, detecting if a protocol has been registered is not easy. In particular, Chrome does not offer anything and the only options consists of hacks (e.g. check for a onBlur event, check for the presence of a plugin / custom font).Obviously, this isn't ideal. Perhaps, in parallel with this work, we should discuss whether or not we need proper support and the implications of that (i.e. fingerprinting? how much work / prioritization?).☆PhistucKOn Mon, Sep 3, 2018 at 11:51 AM Yoav Weiss <yo...@yoav.ws> wrote:What's the feature detection story here?Is there a way for the developer to know if one of the new schemes is not supported in the current browser, and do some other action instead?Checking which protocols are whitelisted would involve trying to register and checking for a SecurityError.
On Tue, 2018-09-04 at 09:34 +0900, Kenji Baheux wrote:
>
>
> On Mon, Sep 3, 2018 at 11:03 PM PhistucK <phis...@gmail.com> wrote:
> > Chrome for Android has the intent:// mechanism, I think.
> > Internet Explorer and/or Edge have an API for launching the calls a
> > callback if it does not work, I believe.
> >
> > So, mostly, no, probably.
> >
>
> On desktop OSes, detecting if a protocol has been registered is not
> easy. In particular, Chrome does not offer anything and the only
> options consists of hacks (e.g. check for a onBlur event, check for
> the presence of a plugin / custom font).
FYI, the original specification supported an
API(isProtocolHandlerRegistered) to check whether the scheme was
registered. However, it has been removed from the spec because it is
not supported by the browsers. So I was implementing the API on Chrome
downstream, but I gave up supporting the API.
- https://github.com/whatwg/html/commit/b143dbc2d16f3473fcadee377d8380
70718549d3
If we need to support a way that checks which scheme is registered,
it looks like *isProtocolHandlerRegistered* can be one of those
candidates. And I still have the prototype.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjuRJ0pZ4%2BmabfU0R-ATVQOdTsE1C0y6qQgb_iJp4aJNg%40mail.gmail.com.
I'm happy with expanding the list, but some of the items on there look a bit suspect.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.Similarly, this proposal introduces a number of what I would consider "non-generic" URL schemes:
- 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.
- 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.
- gmap, bingmap: Seem to be specifically referring to Google Maps and Bing Maps, respectively. Doesn't feel like references to specific websites belong in a web standard. Also, I can't find any documentation for these. "gmap" doesn't seem to be a thing. As far as I can tell, Bing uses "bingmaps", not "bingmap". Searches for both of those seem to mostly just bring up this very proposal.
I think we should scrutinize the list of schemes more carefully.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DuaOE1igy5kniYU7wdv52cfZRom4jOoVofeX3HLo2t5Y%2B43w%40mail.gmail.com.
I could comment on all of those proposals, but it seems useful to have a general conversation about them overall, rather than discussing the same points on them individually.Asanka, would you mind creating a generic issue on HTML for "Consider expanding the set of whitelisted schemes for registerProtocolHandler" or "Consider allowing all schemes (except a blacklist) for registerProtocolHandler", so we can have a web-standards-level discussion about the general policy on expanding the list? Just paste the above language and link to the existing proposals.
On Tue, 4 Sep 2018 at 17:47, Yoav Weiss <yo...@yoav.ws> wrote:On Tue, Sep 4, 2018 at 9:29 AM Matt Giuca <mgi...@chromium.org> wrote:I'm happy with expanding the list, but some of the items on there look a bit suspect.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.
Similarly, this proposal introduces a number of what I would consider "non-generic" URL schemes:
- 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.
- 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.
- gmap, bingmap: Seem to be specifically referring to Google Maps and Bing Maps, respectively. Doesn't feel like references to specific websites belong in a web standard. Also, I can't find any documentation for these. "gmap" doesn't seem to be a thing. As far as I can tell, Bing uses "bingmaps", not "bingmap". Searches for both of those seem to mostly just bring up this very proposal.
I think we should scrutinize the list of schemes more carefully.For some reason, I thought these proposals already landed. Thanks Matt for bringing it to my attention.
I agree that some of these extensions seems overly service-specific. That seems like something that should be discussed at the related spec proposals/issues.My LGTM stands once the spec issue PRs have landed in the spec (which seem like the right place to discuss which of them should or shouldn't be there).
--
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/CAEK7mvrb8UYE0aWRSdEknJGFrF3h1SzSAbJpqWXx6wZQ%2BR8V3g%40mail.gmail.com.
Hi,The API owners met this morning and discussed this intent. It seems that there is not consensus on what to do next - whitelist/blacklist/status quo/other. There appears to be continuing discussion at https://github.com/whatwg/html/issues/3998 for example. We think the best thing to do is to wait for that discussion and others to reach consensus, at which time please re-start this thread. (And if our understanding is incorrect please also tell us.)
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9DWnei4FgReJv1891yL1YKMd_AA7XDQ_11HOFq3UVVDw%40mail.gmail.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/CAM%3DuaOE1igy5kniYU7wdv52cfZRom4jOoVofeX3HLo2t5Y%2B43w%40mail.gmail.com.
-- Frédéric Wang
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DuaOE1igy5kniYU7wdv52cfZRom4jOoVofeX3HLo2t5Y%2B43w%40mail.gmail.com.
-- Frédéric Wang
map, gmap, bingmap, location based on <a href="https://github.com/whatwg/html/issues/2546" style="font-family:Arial" rel="nofollow" target="
bzr, bzr+ftp, bzr+lp, bzr+http, bzr+https, bzr+sftp, bzr+ssh, cvs, cvs+ext, cvs+pserver, cvs+ssh, darcs+http, darcs+https, darcs+ssh, git, git+http, git+https, git+ssh, hg, hg+http, hg+https, hg+ssh, hg+static-http, lp, svn, svn+http, svn+https, svn+ssh based on <a href="https://github.com/whatwg/html/pull/1829" style="font-family:Arial" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fwhatwg%2Fhtml%2Fpull%2F1829\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGbjfaMWp4kKqeSkXKQ-YRJZq9BQw'
--
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/cb28950b-35c8-4d05-9ff4-16d0e2425eb7%40chromium.org.
-- Frédéric Wang
We are proposing the extension of the safe list with the following schemes:
dat, dweb, ipfs, ipns, ssb.
Please see
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/7nHTRUP1EGY
for these ones.
bzr, bzr+ftp, bzr+lp, bzr+http, bzr+https, bzr+sftp, bzr+ssh, cvs, cvs+ext, cvs+pserver, cvs+ssh, darcs+http, darcs+https, darcs+ssh, git, git+http, git+https, git+ssh, hg, hg+http, hg+https, hg+ssh, hg+static-http, lp, svn, svn+http, svn+https, svn+ssh.
Concerns
reported at
https://github.com/whatwg/html/pull/1829#issuecomment-418594058
have not been addressed by reporters.
map, gmap, bingmap, location
Concerns reported at
https://github.com/whatwg/html/issues/2546#issuecomment-418376741
have not been addressed by reporters.
doi
Reporter confirmed there is still interest in this one
https://github.com/whatwg/html/pull/3080
A similar "scheme to encode data as URI" is otpauth, and the community renewed interest https://github.com/whatwg/html/issues/2204
It seems safelisting "doi" and "otpauth"
shouldn't be controversial, but I'm willing to hear feedback from
the Chromium community before opening a separate intent for them
(if ever needed).
Finally, I added these two in Mozilla's standards-position issue
https://github.com/mozilla/standards-positions/issues/339
and they have have been registered at
https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
-- Frédéric Wang