Dealing with access to native messaging applications

[cyberphone]

Although it is claimed that SOP is the foundation for the Web security model, extensions have historically not followed this principle. I have found the following variants for dealing with site access to native applications:

• Strict SOP. This effectively requires that the manifest (application declaration) contains a domain identifier
• User mediation aided by the browser. Each "new" site (host) forces the browser to ask the user if he/she permits access to the native application
• Apple Pay uses a novel approach where each merchant belonging to the "Apple Pay business network" must authenticate themselves to the Apple Pay application before it is started. This process is transparent for the user. This could be coined "member access control" which I think has other applications than payments as well

My conclusion (FWIW) is that exclusively building on the browser as "permission arbiter" will either lead to limited functionality or to an abysmal user experience (including that the "security" obtained this way is not worth just anything in the hands of non-expert users).

I have in my work with native messaging come up with a twist to user mediation which is that the native messaging application supports a "standardized" icon marked BLOCK, i.e. the browser would by default grant access but easily and permanently enable users to selectively block sites they (typically involuntarily) surfed into.

One could imagine a user option making explicit granting a necessity. All users are not the same :-)

[aswan]

@cyberphone I don't understand the issue here. First of all, lets get our terms straight, I assume SOP stands for Same-Origin Policy. Can you elaborate on what you mean by:

extensions have historically not followed this principle

The rest of your message seems to be about direct access to native messaging from web content. That's an interesting topic, but out of scope for a project focused on a browser extension API for native messaging -- in the currently widely used models for browser extensions, extensions frequently run in a context that is not associated with a specific content page or site.

[cyberphone]

extensions have historically not followed this principle

This refers to the predecessor to Native Messaging (NPAPI, ActiveX) which didn't bother about SOP (Same Origin Policy)

The rest of your message seems to be about direct access to native messaging from web content. That's an interesting topic, but out of scope for a project focused on a browser extension API for native messaging -- in the currently widely used models for browser extensions, extensions frequently run in a context that is not associated with a specific content page or site.

Even if access via Native Messaging would only be allowed from a static browser extension (like in Chrome), the majority of applications using Native Messaging does this through a content script which is related to a specific page or site.

[aswan]

Even if access via Native Messaging would only be allowed from a static browser extension (like in Chrome),

Given that this effort is in the browser extensions group, I think that's a quite reasonable simplification.

the majority of applications using Native Messaging does this through a content script which is related to a specific page or site.

In both Chrome and Firefox, native messaging is not directly accessible from content scripts (it is only accessible from background scripts).

[cyberphone]

@aswan As an "interim" the Chrome, Firefox and Edge(?) Native Messaging solutions are fully sufficient since they are primarily targeted to help people who relied on the now deprecated NPAPI and ActiveX schemes.

However, since no mobile browser currently implements Native Messaging, these solution do not appear to be equally suited for full W3C standardization.

Anyway, calling Native Messaging from ordinary web-pages is doable, the extension scheme only makes it slightly more cumbersome.:
https://chrome.google.com/webstore/search/web2native

[frivoal]

This is a tentative resolution of the CG. See the minutes of the discussion. If no dissenting opinion is expressed here within 10 days, this will be considered the consensus of the CG.

As a request to provide native messaging functionality to regular web pages, not just in extensions, this is out of scope for this Community Group. The appropriate forum is likely to be the WebPlatform Working Group or the WICG. The tentative consensus is to close the proposal as out of scope.

[cyberphone]

@florian @aswan Could we have 30 minutes of the TPAC browser extension session dedicated to native messaging?

Starting Apps from the Web (without SOP restrictions or installing specific browser extension code) is already implemented in iOS and Android as well as being extensively used.

Native messaging primarily adds the ability to "talk back" to the invoking Web page which does (as far as I can see...) not introduce "new" security issues since the existing scheme anyway allows a misbehaving App to POST data to any server out there.

The problem is rather that the mobile OSes deal with Web access to native Apps at the OS-level which I obviously do not have a cure for; I rather think this is the most future-proof way of addressing this topic.

[frivoal]

@florian @aswan Could we have 30 minutes of the TPAC browser extension session dedicated to native messaging?

We will spend some time during the TPAC meeting on native messaging from browser extensions. Whether that will be 30 minutes or not will depend on what other topics we need to cover, but we will speak about it.

However, I do expect that this will be a crowded agenda, and I don't think we will have time to talk about native messaging for other contexts that extensions. If there was a concrete proposal (even if it was in early stages and far from final), either from another CG or WG, or from an individual, we could consider whether it also solves our use cases and whether we should switch to it or not, but I do not think that such discussion would be productive if we are only talking about the possibility of such a mechanism, without having something concrete to evaluate.

Starting Apps from the Web (without SOP restrictions or installing specific browser extension code) is already implemented in iOS and Android as well as being extensively used.

Native messaging primarily adds the ability to "talk back" to the invoking Web page which does (as far as I can see...) not introduce "new" security issues since the existing scheme anyway allows a misbehaving App to POST data to any server out there.

The problem is rather that the mobile OSes deal with Web access to native Apps at the OS-level which I obviously do not have a cure for; I rather think this is the most future-proof way of addressing this topic.

You may well be right about this, but this CG is not an appropriate place to look into creating a native messaging system that would work without extensions. If a concrete proposal for such a system is developped (in another CG or WG, or by an individual), we could look at it to see if it effectively solves the problems we have and allow us to drop some of the things we otherwise want to introduce, but we are not the place for creating this proposal. It is not only that this is out of scope from an administrative point of view, we don't have the right people around the table to be able to have this discussion seriously.

[florian]

Please stop @ mentioning me. I get an email for every one of these and it subscribes me to this thread, which means even more unnecessary emails.

[frivoal]

Appologies. the @ mention was meant for me, but my handle is @frivoal, not @ ... florian. And my copying the text to reply to it, I made the same mistake.

[frivoal]

Follow up action in #6

[cyberphone]

Although this topic has been labelled as "invalid" it may be worth noting that what I'm proposing in no way is security-wise incompatible with the "preferred" solution. That is, a manifest that is (in some way) associated with the native executable could declare things like:

"callable_from": ["https://*.example.com", "extension:[email protected]"]

Yes, it wouldn't be Chrome-compatible but that's not equivalent to useless :-)

The point with this is that mixing "in-browser" extensions and native messaging becomes a developer option instead of something bolted into the platform. GitHub client, Spotify, and my experiments with payments do not seem to be candidates for mixing since they already have powerful native GUIs.