This is an introduction/summary post which will link to individual articles about browser mechanisms for communicating directly between web content and native apps on the local computer.
This series aims to provide, for each mechanism, information about:
- On which platforms is it available?
- Can the site detect that the app/mechanism is available?
- Can the site send more than one message to the application without invoking the mechanism again, or is it fire-and-forget?
- Can the application bidirectionally communicate back to the web content via the same mechanism?
- What are the security implications?
- What is the UX?
tl;dr: Apps can register protocol schemes. Browsers will spawn the apps when navigating to the scheme.
Characteristics: Fire-and-Forget. Non-detectable. Supported across all browsers for decades, supported on desktop platforms, but typically not mobile platform. Prompts on launch by default, but usually can be disabled.
Native Messaging via Extensions
Blog Post – Coming someday. For now, see nativeMessaging API.
tl;dr: Browser extensions can communicate with a local native app using stdin/stdout passing JSON between the app and the extension. The extension may pass information to/from web content if desired.
Characteristics: Bi-directional communications. Detectable. Supported across most modern browsers; not legacy IE. Dunno about Safari. Prompts on install, but not required to use.
File downloads (Traditional)
Blog Post – Coming soon.
tl;dr: Apps can register to handle certain file types. User may spawn the app to open the file.
Characteristics: Fire-and-Forget. Non-detectable. Supported across all browsers. Prompts for most file types, but some browsers allow disabling.
File downloads (DirectInvoke)
Internet Explorer/Edge support DirectInvoke, a scheme whereby a file handler application is launched with a URL instead of a local file.
Characteristics: Fire-and-Forget. Non-detectable. Windows only. Supported in Internet Explorer, Edge 18 and below, and Edge 78 and above. Degrades gracefully into a traditional file download.
Blog Post – Coming someday, maybe.
Bi-directional. Awkward. “Looks like” a file upload or download in most ways.
Blog Post – Coming someday, maybe.
Local Web Server
Blog Post – Coming someday.
tl;dr: Apps can run a HTTP(S) server on localhost and internet webpages can communicate with that server using fetch/XHR/WebSocket/WebRTC etc.
Characteristics: Bi-directional communications. Detectable. Supported across all browsers. Not available on mobile. Complexities around Secure Contexts / HTTPS, and loopback network protections in Edge18/IE AppContainers.
Local Web Server- Challenges with HTTPS
In many cases, HTTPS pages may not send requests to HTTP URLs (depending on whether the browser supports the new “SecureContexts” feature that treats HTTP://localhost as a secure context, and not as mixed content. As a result, in some cases, applications wish to get a HTTPS certificate for their local servers. This is complex and error-prone to do securely. Many vendors used a hack, whereby they’d get a publicly-trusted certificate for a hostname (e.g. loopback.example.com) for which they would later use DNS to point at 127.0.0.1. However, doing things this way requires putting the certificate’s private key on the client (where anyone can steal it). After the private key is released, anyone can abuse it to MITM connections to servers using that certificate. In practice, this is of limited interest (it’s not useful for broadly attacking traffic) but compromise of a private key means that the certificate must be revoked per the rules for CAs. So that’s what happens. Over and over and over.
The inimitable Ryan Sleevi wrote up a short history of the bad things people do here: https://twitter.com/sleevi_/status/1202046844240572416?s=20 after Atlassian got dinged for doing this wrong.
Prior to Atlassian, Amazon Music’s web exposure can be found here: https://medium.com/0xcc/what-the-heck-is-tcp-port-18800-a16899f0f48f
Andrew (@drewml) tweeted at 4:23 PM on Tue, Jul 09, 2019:
The @zoom_us vuln sucks, but it’s definitely not new. This was/is a common approach used to sidestep the NPAPI deprecation in Chrome. Seems like a @taviso favorite:
Anti virus, logitech, utorrent. (https://twitter.com/drewml/status/1148704362811801602?s=03)
Bypass of localhost CORS protections by utilizing GET request for an Image
There exist WebRTC tricks to bypass HTTPS requirements https://twitter.com/sleevi_/status/1177248901990105090?s=20
How to do this right? There’s a writeup of how Plex got HTTPS certificates for their local servers.
Variant: Common Remote Server as a Broker
An alternative approach would be to communicate indirectly. For instance, a web application and a client application using HTTPS/WebSockets could each individually communicate to a common server which brokers messages between them.
While not directly an API to communicate with a local app, the getInstalledRelatedApps() method allows your web app to check whether your native app is installed on a user’s device. Learn more.
AppLinks aka AppURIHandlers
Allow navigation to certain namespaces (domains) to be handed off to a native application on the local device. So, when you navigate to
https://netflix.com/, for instance, the Netflix App opens instead.
This feature is commonly available on mobile operating systems (e.g. Android) and was supported briefly in Legacy Edge on Windows 10, where it caused a fair amount of user annoyance, because sometimes users really do want to stay in the browser.
Legacy Plugins/ActiveX architecture
Characteristics: Bi-directional communications. Detectable. Support has been mostly removed from most browsers. Generally not available on mobile. One of the biggest sources of security risk in web platform history.
Similar to App Protocols, a web page can launch an application to handle a particular task. Learn more.
Android Instant Apps
Basically, the idea is that navigating to a website can stream/run an Android Application. Learn more.