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. Prompts by default, but 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 someday.
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.
Local Web Server
Blog Post – Coming someday.
tl;dr: Apps can run a HTTP(S) server on localhost and 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.
In many cases, HTTPS pages may not send requests to HTTP URLs (depending on whether the browser supports the new “SecureContexts” feature that allows HTTP://LOCALHOST), in some cases applications wish to get a HTTPS certificate for their local servers. This is complex and error-prone. There’s a writeup of how Plex got HTTPS certificates for their local servers.
A nice writeup of 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
WebRTC tricks to bypass HTTPS requirements https://twitter.com/sleevi_/status/1177248901990105090?s=20
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.
AppLinks in Edge/Windows
Allow navigation to certain namespaces (domains) to be handed off to a native application on the local device.
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.
Dunno much about these.
Android Instant Apps
Dunno much about these. Basically, the idea is that navigating to a website can install/run an Android Application.