Interprocess communication between browser extension and native application

Question

How can an interprocess communication be estabilished between a browser extension and a native application? Is there any cross-platform (Linux and Mac OS X) and cross-browser solution (Firefox, Chrome, Safari)?

The only idea that comes to my mind is using native Web technologies, i.e. embed a HTTP server in native application and use XmlHttpRequest or WebSockets. However, this sounds like clunky overkill with handful of issues (e.g. security). Is there a better alternative?

Insurer

Cross-browser? Probably not. A browser is designed to talk to web servers, and the more cross-browser a solution you want, the less are the chances that you have something extra to that. – Georgia

Actually, some time ago NPAPI would probably be a way, but at least in Chrome it's deprecated completely for extensions. – Georgia

By cross-browser I mean solution that allows me to have one "protocol" and one "server" component, even if "browser-side" implementations would be different. – Erichericha

NPAPI is also deprecated when it comes to Firefox (well, kinda). addons.mozilla.org does not accept submissions of NPAPI plugins or add-ons containing such plugins since quite some time. – Shultz

Answer 1

I believe the most commonly used method is websocket connections. Two examples I can think of are 1Password and LiveReload (source code available).

As far as I know, you need to open the websocket connection from within your global page to avoid cross-domain restrictions.

Also, in the past I have seen other apps watch and modify an extension's settings file. The extension just reads and writes from it's own settings store, while the other process watches the preferences file for changes. I believe this is less reliable and doesn't conform to sandboxing requirements for the Mac App Store so I would recommend the websockets method.

Daltondaltonism

Is it possible to run WebSockets over AF_UNIX sockets instead of TCP? – Erichericha

AF_UNIX would exclude Windows (but you seem to be only after Linux and OSX anyway)... However, you cannot even use raw TCP in chrome extensions, only HTTP/XHR and WebSockets (to some extend). You can use domain sockets in Firefox relatively hassle-free, though. – Shultz

Using raw sockets is not necessary. Constructing WebSocket URI that points to unix domain socket instead of HTTP host would be fine. – Erichericha

@el.pescado: why do you need Unix domain socket? why isn't TCP loopback as transport "good enough"? – Hyalite

@oberstet: Unix domain sockets "live" on filesystem, wchich is convienient, as 1) sockets can be "placed" in users' home directories in multiuser systems, 2) filesystem permissions are enforced on them – Erichericha

I think your question about UNIX sockets deserves a separate question. – Georgia

Answer 2

As this is one of the higher voted questions relating to this, I will just note here that this question and accepted answer is from before Mozilla dropped XPI/XUL extensions went WebExtensions only (circa 2017).

For modern browsers "Native Messaging" is used, which sends JSON + UTF-8 encoded messages over stdin, with a message length prefix. There are just some manifest and location differences between FF and Chrome. There is connectionless messaging and connection-based messaging.

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging

https://developer.chrome.com/docs/extensions/develop/concepts/native-messaging

Cressida