Soni's Blog

Thoughts on Web-based Protocol Handlers

Web-based Protocol Handlers are a nifty feature of desktop browsers, which allows a website like gmail to present itself as an email client for when you click an email link on a website, or other similar use-cases. On some systems, they can even integrate with system Protocol Handlers. However, they have some issues which make it hard to successfully deploy them:

• Web-based protocol handlers do not work on mobile. Websites cannot register protocol handlers on mobile at all.

• There is no fallback mechanism when clicking a link that needs a protocol handler. If web protocol handlers are unsupported or unavailable for a given protocol, clicking links often does nothing. (Sometimes however, the browser does tell the user that no protocol handler is available.)

• Websites that register protocol handlers are bad at communicating what they are for and how they can be used by the user. This is not helped by the UI around them.

The following changes and usage guidelines would make them more palatable to the user:

• Allow websites to define fallback handlers. This would be similar to how <base> elements are used to set a fallback for relative URLs, so that website authors don't have to worry about the user not being able to open certain links.

  In particular, website authors should use this mechanism to provide either their preferred handler (for example, having all geolocation URIs open in Google Maps by default), or provide a helpful page for what the URI does (for example, a help page for how to set up an email client on Windows so it can handle mailto: URIs). They would show up as any other (web-based) protocol handler, except for being able to "always use for this protocol".

  This is no more dangerous than being able to link to an arbitrary webpage, and if anything is less useful for fingerprinting than the existing mechanisms: they would always detect a protocol handler - the fallback protocol handler - if one attempted to use it for fingerprinting. This is because it's not actually possible to identify what target a protocol handler points to, only the user and the browser are aware of those. One can also have multiple handlers for a given protocol. (Note, however, that it should not be possible to test whether a protocol handler exists in the first place. This could be accomplished by providing a helpful error message in the handler selection dialog.)

• Require web-based protocol handlers to be registered in an onclick handler, ideally through a <button> element. The current UI is confusing and this would require website authors to describe what protocol handlers do. Additionally, making the "Would you like to use this protocol handler?" confirmation prompt use a similar dialog to "Would you like this website to send notifications?" would make it less scary to the user. (The "handle bar" that Firefox uses is scary to the user.)

  This is slightly different to how the likes of desktop notifications are handled, as they don't specificaly require an onclick on a button. It is the best way to have website authors describe what a protocol handler is and what the user can do with one, however. Hopefully the button element requirement also pushes the web-based protocol handler registration to a "user settings" or "integration settings" pane on the website.

• Support web-based protocol handlers on mobile browsers. Legit, it need not have system integration, just work within the browser. Many use-cases for web-based protocol handlers do not involve system integration. (In particular, web+ protocol handlers do not require system integration.)

  At the very least handling them with the help of some website-defined fallback handlers would already fix the main deployability issue with web-based protocol handlers, which is that links to "custom" protocols currently fail silently on mobile. Not being able to register them is a much smaller issue when you can provide a helpful fallback. Requiring users to install arbitrary apps is not a good solution.

These come from our own experiences trying to deploy web-based protocol handlers for GAnarchy, as well as from talking to other developers who have worked with web-based protocol handlers, such as Mastodon developers. Furthermore, there are alternatives to web-based protocol handlers that are significantly more privacy-invasive, and yet work on mobile. Making web-based protocol handlers deployable wouldn't make those go away overnight, but it would be a step in the right direction.