Intent to Implement and Ship: Additional safelisted schemes for "registerProtocolHandler"

[Asanka Herath]

Contact emails

asa...@chromium.org

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

[Domenic Denicola]

I just want to weigh in with a strong +1 from the spec-editor side of this.

For the last few years in which I've been editing HTML, several developers have popped up asking to expand the scheme list of registerProtocolHandler() to make it more useful, as encouraged by the spec. ("This list can be changed. If there are schemes that ought to be added, please send feedback.") It's been frustrating to tell them "that sounds good, but no browser seems to be interested, so we can't accept this proposal". It felt like the spec was trying to do the right thing by using a safelist instead of a blocklist, but that led to an unfortunate stagnation as expanding the safelist never happened.

I'm excited that Asanka is taking this on, and I hope this intent goes through and we can make developers happy by increasing the utility of registerProtocolHandler().

[Gyuyoung Kim]

> 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.

Gyuyoung.

> -- 
> 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.gm
> ail.com.

[Domenic Denicola]

The additions to the spec have been reviewed and approved. They are only waiting on implementation interest and tests, both of which this intent provides.

---

From: Gyuyoung Kim <gyuyou...@chromium.org>
Sent: Thursday, August 30, 2018 23:32
To: Asanka Herath
Cc: blin...@chromium.org
Subject: Re: [blink-dev] Intent to Implement and Ship: Additional safelisted schemes for "registerProtocolHandler"

> 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

[Asanka Herath]

I understand the concern with the number of schemes being proposed. I encourage folks to pick on individual schemes and not consider this to be a package deal. I.e. if objections are raised against specific schemes, I'd be happy to proceed with the rest.

That said, the new schemes require the same kind and level of scrutiny. Which is why I believe including all of them in the same proposal is a better trade-off in terms of eyeball time.

GGyuyoung

[Gyuyoung Kim]

If the spec has been approved as well as the plan doesn't consider to
add the new schemes at once, looks good to me to add the new schemes to
the whitelist.

Gyuyoung.

On Fri, 2018-08-31 at 10:13 -0400, Asanka Herath wrote:
>
>
> On Fri, Aug 31, 2018 at 8:58 AM Domenic Denicola <d...@domenic.me>
> wrote:
> > The additions to the spec have been reviewed and approved. They are
> > only waiting on implementation interest and tests, both of which
> > this intent provides.
> >
> >

[Yoav Weiss]

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?

--
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.

[PhistucK]

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.

☆PhistucK

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.

[Kenji Baheux]

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?).

 

 

☆PhistucK

On 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.

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.

[Yoav Weiss]

On Tue, Sep 4, 2018 at 2:34 AM Kenji Baheux <kenji...@chromium.org> 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).

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?).

 

 

☆PhistucK

On 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.

 

Oh, OK. That's the compatibility piece that I was most worried about. So once we support these new schemes, developers can try to register them and create some fallbacks (e.g. notify users that they failed) by catching those exceptions.

[Gyuyoung Kim]

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.

Gyuyoung.

> 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?).
>  
>  
> >
> > ☆PhistucK
> >
> > On 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 Mon, Sep 3, 2018 at 9:47 AM Gyuyoung Kim <gyuyoung.kim@chromiu

> > > m.org> wrote:
> > > > If the spec has been approved as well as the plan doesn't
> > > > consider to
> > > > add the new schemes at once, looks good to me to add the new
> > > > schemes to
> > > > the whitelist.
> > > >
> > > > Gyuyoung.
> > > >
> > > > On Fri, 2018-08-31 at 10:13 -0400, Asanka Herath wrote:
> > > > > 
> > > > > 

> > > > > On Fri, Aug 31, 2018 at 8:58 AM Domenic Denicola <d@domenic.m

> > > dev/CACj%3DBEh9P1Oy9aYVQRunRhqUvOYbD%3DTpCtte3S8d43W_oxXcWQ%40mai
> > > l.gmail.com.
> > >

[Yoav Weiss]

LGTM1

On Tue, Sep 4, 2018 at 7:50 AM Gyuyoung Kim <gyuyou...@chromium.org> wrote:

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.

That seems like a related feature, that will probably require it's own intent.

[Matt Giuca]

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.

Perhaps if there is enough interest in greatly expanding this list, it would be better to explore swapping this whitelist out for a blacklist. Expanding the list does seem useful, but it seems to unfairly favour existing technologies if we whitelist specific schemes in at the API level (what if I want to invent a new revision control system? Now I face the uphill battle of not only winning over Git users, but also getting my scheme whitelisted in HTML so my web app can run as smoothly as incumbents). I've never understood the security rationale for preventing sites from registering arbitrary schemes, other than well-known schemes like "http" and "file".

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.

[Gyuyoung Kim]

Though *isProtocolHandlerRegistered* has been removed from
specification, can we add it? If it's possible, I'd like to send a new
intent soon.

Gyuyoung.

[Yoav Weiss]

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).

[Matt Giuca]

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.

[Daniel Vogelheim]

Hi Asanka, can you please file a launch bug for this and sign it up for privacy & security reviews, once you're ready? Thanks!

--
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.

[Asanka Herath]

Thanks all for the thoughtful reviews. Replies inline:

On Tue, Sep 4, 2018 at 4:09 AM Matt Giuca <mgi...@chromium.org> wrote:

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.

mgi...@chromium.org: I filed this issue for discussing a blocklist for schemes vs. a safelist. I'm assuming that this proposal is blocked on a resolution there unless we determine that safelist is the short term option. Also regarding comments on individual schemes: I've passed along the comments to the issues that are proposing the respective schemes. I also believe those proposals are where the scheme specific comments should go since we now have a place to discuss the inclusion/exclusion criteria.

 

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.

mgi...@chromium.org: Yup. Both these points go into the "where do we draw the line" question, for which the current answer appears to be "known and has developer interest." I agree with the point about this method of inclusion being a barrier for emerging or lesser known technologies and mentioned it in this issue. I suggest we hash out the inclusion/exclusion criteria in that issue.

• 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.

mgi...@chromium.org: I've passed along these sentiments to the whatwg/html issue proposing the schemes. I also commented on the location scheme being confusing and redundant, and suggested going with maps (which is a provisionally registered scheme) instead of map (which isn't).

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.

yo...@yoav.ws: Approved, but not landed yet.

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).

yo...@yoav.ws: Thanks! I'll update this thread once we reach a consensus over at whatwg/html.

voge...@chromium.org: I filed a launch bug here.

[Matt Giuca]

Thanks very much for following up on all the issues, Asanka. Will continue discussions there.

[ju...@protocol.ai]

Greetings! 

I work on the IPFS project, and want to say Thank You!! This support would be HUGE for decentralized web protocols, and many others.

It has been tremendously difficult to work around not having protocol handler resolution, and all workarounds come with nasty UX problems and adoption barriers. (localhost leaking onto the address bar, proxies, etc). This support would be tremendously valuable to all our projects, to all the developers, and most of all to all our users. We are thrilled to see this progress -- thank you very much for listening :)

Thank you,

Juan

[Matthew Menke]

I assume we'd display "not secure" in the omnibox for all of these?  Even for the nominally secure protocols, there's effectively a MitM (Possibly an encrypted one, of course), meaning we can't verify where the response came from.

[Matt Menke]

Oops, Domenic Denicola kindly pointed out to me that the original email already mentioned we don't display these URLs in the omnibox.  Sorry about the spam (And thanks Domenic!)

[Chris Harrelson]

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.)

Thanks,

Chris

--
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.

[Asanka Herath]

On Tue, Sep 25, 2018 at 12:19 PM Chris Harrelson <chri...@chromium.org> wrote:

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.)

This is correct. This intent is blocked on a decision on https://github.com/whatwg/html/issues/3998 .

I'll update the thread with the outcome once a decision has been made.

Thank you!

- Asanka

 

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.

[Frédéric Wang]

Hi,

Thank you everybody for contributing to the discussion. I re-read all the comments but it seems this discussion (in blink-dev and at WHATWG) has stalled for 1-2 years. I'm not sure what's the current status but I'd like to bring some updates:

* Igalia is willing to take over the necessary work to at least whitelist the distributed web protocols (which seem to be among the "uncontroversial" ones and have their own feature dashboard) in Firefox and Chromium. We want to try and add support for them soon.

* More protocols were requested by web developers e.g.
  otpauth (https://github.com/whatwg/html/issues/2204)
  ethereum (https://github.com/whatwg/html/issues/4287)

* Status for other web engines:
  - Edge: Switched to Chromium so not sure it's still relevant to treat this separately in the intent-to processes...
  - Safari: There was opposition to registerProtocolHandler in webkit-dev's 2015 thread ; asking on WebKit's slack channel last week, they would prefer a whitelist if it is implemented.
  - Firefox: As indicated in the original intent, WebExtension's protocol_handler support distributed web schemes so it is inconsistent with blocking them in registerProtocolHandler. I said, Igalia is happy to submit patches to Firefox for at least these schemes. Also, reading the WHATWG issue and checking again with Mozilla people recently, it seems they'd prefer a whitelist in the short term.

I commented on the WHATWG "switch to blacklist" issue ( https://github.com/whatwg/html/issues/3998 ) but given all user requests that have been pending for 1-4 years and the current position of other web engines, it seems the best option in the short term is to extend the whitelist. WDYT?

--
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

[bay...@gmail.com]

Edge's position is that we support extending the whitelist, and we fancy that our opinions are still relevant.

Microsoft is also mulling plans to propose new schemes to be added to the allowlist in support of our efforts to invest heavily in PWA versions of popular applications. (There's mention of that here: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/URLProtocolHandler/explainer.md)

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

[Fabio Rocha]

Thanks for bringing up our explainer, Eric. +1 to everything you said.

The intent to support other protocols also briefly came up on the intent-to-prototype discussion and we'll be soon proposing those to be added to the spec. 

I'm glad Fred is reviving this conversation as there's no consensus on switching to a blocklist on the horizon. The obvious option is to extend the allowlist - which Microsoft also wants to do.

My hope from this conversation is that if we do go this route, having other protocols added to the whitelist is something that doesn't take years or months -- assuming the protocols are well understood/non-controversial/etc.  

Reading the discussion there are some guidelines whitelist proposals should follow and that we should probably extract from this thread and document somewhere?

• Have proposed additions to the spec reviewed.
• Have implementation interest and tests.
• Do not add many protocols at once.
• Explicitly mention security issues with the protocols proposed, if any.
• Etc

Now, an important issue I don't think it's completely addressed if we go the whitelist route is the "companies or services' names vs generic names" issue raised by mgiuca@. My thinking is that we could lessen the concerns here by proposing categories of protocols, in a way that we're not tipping the scales one way or another, similar to Asanka's original proposal (broken apart in smaller proposals), which seems to be fair to well known protocols in their categories. Thoughts?

[sligh...@chromium.org]

Hey all,

Discussed at some length at today's API OWNERS meeting. There isn't strong feeling, it seems, about changing approach from allowlists to blocklists, but it might be good to move that discussion to a separate intent.

Regarding specific extensions to the allowlist, LGTM1.

Personally, I also agree that it would be great for someone to write up a doc as Fabio suggests for us to perhaps adopt project-wide. Do you want to take that on, Fabio? Can schedule some OWNERS time to discuss when there's a concrete process suggestion. WDYT?

Regards

• map, gmap, bingmap, location based on <a href="https://github.com/whatwg/html/issues/2546" style="font-family:Arial" rel="nofollow" target="

[Frédéric Wang]

On 23/04/2020 16:10, bay...@gmail.com wrote:
> Edge's position is that we support extending the whitelist, and we
> fancy that our opinions are still relevant.
>

Apologies, I think I expressed myself poorly. This is referring to the
"Interoperability and Compatibility Risk" section of the intent-to-ship.
Since Edge switched to Chromium and IIUC does not ship different web
platform features, I'm not sure it's still relevant to mention Edge's
position or the position of any other Chromium-based browsers as an
interoperability risk. Obviously, Microsoft's position is still relevant
and welcome but can be argued directly in the blink-dev thread :-)
Anyway, that was more a meta question regarding intent-to-* templates...

Frédéric Wang

[Fabio Rocha]

Thanks, Alex. 

Yes, I'm happy to write that doc and share it with the community.

About your LGTM, just a quick clarification. Are you supporting the specific protocols Fred is proposing to add or are you, in general, agreeing with the idea of having proprietary protocols proposed to be safelisted -- although those things might go hand in hand. Just wondering if the latter was part of the things discussed by API owners today.

• 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&#39

[Frédéric Wang]

Hi,

Thank you Alex and Fabio. I think having a doc is a good idea, I'm happy to help review it if necessary. It seems many of the suggestions (spec addition, tests, implementer interests) are already implied by WHATWG rules.

IIUC the API owners' conclusion was more about the general approach (whitelist VS blacklist) that on specific protocols discussed here. Checking again the list in this thread:

* dat, dweb, ipfs, ipns, ssb: No negative feedback, still interest from the community and has its own chromestatus entry. I updated the WHATWG thread and I'll open a separate intent-to-ship for that one.

* doi: No negative feedback. I updated the WHATWG thread to see if there is still interest in this from web developers.

* Version control and maps: Negative feedback for this one (already reported to the WHATWG threads), so I guess whether we want them is still open. See https://groups.google.com/a/chromium.org/d/msg/blink-dev/29sFh4tTdcs/sQm7xcTMEAAJ

* New proposals (otpauth, ethereum and more by Microsoft): Recent interest (at least for the Microsoft's ones). These were not in the initial intent, so I guess they need to be discussed. In particular I don't know whether Matt Giuca's concerns apply for them too.

--

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

[Mike West]

I'm a bit concerned about `gmap` and `bingmap`, as it seems that developers at Google and Microsoft might reasonably expect that the content of URLs targeting those protocols would be directed to their respective applications. Do you have any idea what information is generally conveyed in those URLs?

These examples give me pause with regard to the allowlist/blocklist discussion; it's unclear what risk exists in current usage of protocols handled by native applications. Have y'all done any analysis of that aspect of protocol registration?

-mike

[Frédéric Wang]

On 30/04/2020 20:29, Mike West wrote:
> I'm a bit concerned about `gmap` and `bingmap`, as it seems that
> developers at Google and Microsoft might reasonably expect that the
> content of URLs targeting those protocols would be directed to their
> respective applications. Do you have any idea what information is
> generally conveyed in those URLs?

As I said I think there were other concerns reported on these two so I
don't personally plan to consider them for now. I tried to extract the
ones that seemed not controversial in a separate thread (see "Add
schemes for decentralized web protocols"). Probably other protocols that
people find interesting should be handled separately too, following the
guideline document Fabio is preparing.

BTW, one thing proposed by Mozilla was to register new protocols as IANA
URL scheme (
https://github.com/whatwg/html/pull/5482#issuecomment-618973427 ) which
might maybe help to verify and analyze how relevant the proposals are.

> These examples give me pause with regard to the allowlist/blocklist
> discussion; it's unclear what risk exists in current usage of
> protocols handled by native applications. Have y'all done any analysis
> of that aspect of protocol registration?

I'm not entirely sure I understand what you mean by the
allowlist/blocklist discussion, but note that the problem you are
mentioning already exists with the current protocols (e.g. mailto: or
ircs:) ; or even between two native applications handling the same
protocol. The typical solution is to provide an UI similar to
https://raw.githubusercontent.com/MicrosoftEdge/MSEdgeExplainers/master/URLProtocolHandler/images/windowsresolver.png
so that the user can decide the one they want to use. To be honest, I'm
not sure Chromium already has such an interface but I saw one for Firefox.

--
Frédéric Wang

[Frédéric Wang]

Hi,

Things are getting a bit complicate, so I'm trying to summarize the status here.

On 30/08/2018 23:18, Asanka Herath wrote:

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