Browser Architecture: Web-to-App Communication Overview

This is an introduction/summary post which will link to individual articles about browser mechanisms for communicating between web content and native apps on the local computer.

Application Protocols

Blog Post

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.

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.

nativeMessaging API

File downloads

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.

Internet Explorer/Edge DirectInvoke is a variant of this one whereby the handler application gets a URL instead of a file.

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/etc.

Characteristics: Bi-directional communications. Detectable. Supported across all browsers. Not available on mobile. Complexities around Secure Contexts / HTTPS, and loopback protections in Edge18/IE.

Notes: https://wicg.github.io/cors-rfc1918/#mixed-content

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 – https://t.co/yG6RgrcAjm
logitech – https://t.co/tjf1KwOaqn
utorrent – https://t.co/sWlvoKDt56
(https://twitter.com/drewml/status/1148704362811801602?s=03)

Bypass of localhost CORS protections by utilizing GET request for an Image
https://bugs.chromium.org/p/chromium/issues/detail?id=951540#c28

View at Medium.com

AppLinks in Edge/Windows

Allow navigation to certain namespaces (domains) to be handed off to a native application on the local device.

https://blogs.windows.com/windowsdeveloper/2016/10/14/web-to-app-linking-with-appurihandlers/

https://docs.microsoft.com/en-us/windows/uwp/launch-resume/web-to-app-linking

Legacy Plugins/ActiveX architecture

Please no!

Android Intents

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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s