Html: Proposal: navigator.supportsProtocolHandler

[GianlucaGuarini]

At moment exist 2 APIs to register and unregister a custom protocol handler but there is no navigator method to check whether a custom protocol is supported.

Use case

I want to render a link with a custom protocol only if it's available otherwise I will fallback. For example:

const hasWhatsapp = navigator.supportsProtocolHandler('whatsapp')

html`
  <a href=${ hasWhatsapp ? 'whatsapp://stuff' : 'http://fallback.com' }>
    Send me a message
  </a>
`

Interface proposal

interface mixin NavigatorContentUtils {
  void registerProtocolHandler(DOMString scheme, USVString url, DOMString title);
  void unregisterProtocolHandler(DOMString scheme, USVString url);
  boolean supportsProtocolHandler(DOMString scheme);
};

API variations

This API could be also asynchronous in case the computation might be too expensive blocking the main thread.

(async function main() {
  const hasMailto = await navigator.supportsProtocolHandler('mailto')
}())

[annevk]

This functionality was intentionally removed due to the tracking implications.

[GianlucaGuarini]

@annevk thanks for your feedback but de facto many current online tools rely on user agent sniffing to support this feature or simply don't work properly.

• Share this
• Add this

I might be too naive but tracking if the users' browser supports a certain protocol shouldn't raise more privacy concerns than tracking all the other readonly navigator properties like navigator.geolocation for example.

On the other hand I also think that prompting whether the user wants to share his/her browser protocols support seems a bit too much for me.

[annevk]

Being able to determine whether a user uses X is a thing that browsers would like to prevent.

[GianlucaGuarini]

@annevk you are right but:

1. Detecting custom protocols support is already possible today in a hacky way (demo)
2. Browser vendors can block this check like they block reading from the navigator.userAgent

Fixed 😄

Being able to determine whether a user uses X is a thing that browsers would users might like to prevent.

[Yay295]

The proper solution for this would be to provide both links. If they have WhatsApp they can click the WhatsApp link, otherwise they can click your fallback link. And maybe they have WhatsApp but don't want to use it for this; providing both links would give them a choice.

Jut because something can be done doesn't mean we should make it easier to do.

[GianlucaGuarini]

@Yay295 thanks for your feedback but this feature is meant to be used with any kind of protocol, it's not WhatsApp specific.

And maybe they have WhatsApp but don't want to use it for this; providing both links would give them a choice.

How many users understand the difference between WhatsApp and WhatsApp Web? I think for example about my father trying to make such a decision without having any clues about it.

Our job as developers is to provide the best experience for our users depending on their needs: if a user doesn't want to be tracked he/she could disable the protocol check directly in her/his browser via privacy flags.

The solution provided is also not future proof, imagine if in the near future we want to use the pay: protocol for example:

<ul>
  <li>
    <a href="pay://3$?account=123abc&[email protected]">
      Pay now native
    </a>
  </li>
  <li>
    <a href="https://fallback.com?amount=3$&account=123abc&[email protected]">
      Pay now web
    </a>
  </li>
</ul>

The navigator.supportsProtocolHandler will allow us to enhance the user experience avoiding redundant UI elements completing an API (registerProtocolHandler) that is already available in our browsers today.

[ericlaw1979]

To reiterate annevk's point, this was very explicitly a design consideration for the Edge team, and a gating consideration of the api design around the msLaunchUri API. In particular, allowing a site to silently enumerate the user's protocol handlers is a huge fingerprint which must be avoided. That's even more true when the presence of a protocol handler might reveal something private about that user (e.g. they have some app installed which correlates with some personal trait, e.g. gender, sexual orientation, political affiliation).

The msLaunchUri API allows a site to attempt to invoke a protocol and determine that it failed, but this isn't silent, and a user declining is not directly distinguishable from the protocol not being installed.

https://blogs.msdn.microsoft.com/ieinternals/2011/07/13/understanding-protocols/

[annevk]

I'm going to close this as OP cannot be addressed as-is due to the privacy issues. A different design should probably start at https://discourse.wicg.io/ or potentially a new issue if there's already some amount of buy-in.