External Protocol Handling Specification

Abstract

The document describes a new standard API for handling external protocols within browsers.

Introduction

Currently, there exists no standard good standard mechanism in browsers for handling links to external content; everything is done via repurposing other features with various deficiencies:

Load via iFrame/img/etc elements. Currently the de-facto standard.
Problems: iFrame are designed to include different documents in a HTML page; that they work to jump-start launch external links is a side-effect. Using them forces a developer to hide junk content in their web page, and the lack of visibility into the external protocol handling makes it difficult to clean up efficiently.
Change window.location
Problems: Interrupts the current page load. Triggers unload events. Also problematic theoretically, as the developer is not sending the user to a new page.
Add a hyperlink to page content
Problems: Interrupts the current page load. Triggers unload events. Reliable as a fallback, but requires user interaction.

In addition, relying on workarounds in general leads to other problems:

browser updates can cause breaking changes because the feature is secondary
feature set is not robust
The URI is loaded as part of the browser workflow, when often what is needed is to load a URI as part of an application workflow.

Proposal

Internet Explorer already includes a solution in the form of msLaunchUri. I propose this method be adapted as a cross-browser standard in the form of navigator.launchUri.

navigator.launchUri(uri, successCallback, noHandlerCallback)

Parameters:

uri

URL containing protocol of the document or resource to be displayed.

successCallback

Function to be executed if the protocol handler is present.

noHandlerCallback

Function to be executed if the protocol handler isn't present or the user declined the request to open the handling application.

Benefits

Provides an API method to launch external protocols, avoiding hacky workarounds
Provides feedback to the web application so fallbacks can be executed if the client is unable or unwilling to fulfill the request

Potential Concerns

Privacy

The API callback appear to present a risk of exposing user information (in the form of capabilities) to a malicious application, and increased fingerprinting exposure is obviously a privacy no-no. There are a number of mitigating factors here, though:

Capabilities are reported as part of an API request, not as part of a header - harder to access
Capability report is gated by a request that would likely requires user interaction/approval - more difficult to access information on multiple protocols
Application cannot distinguish between "user doesn't have handler" and "user declined request"