Re: Native Messaging (Was: Core API Proposal)

Hi Andrew,

I believe the ultimate "arbitrator" will be the scheme used in Android which we currently know nothing about.

I do not promote the idea "provide a convenient way to safely run arbitrary native code" but a scheme that gives third-parties' tools for securely extending browsers as an alternative to Web API standardization projects that take forever and often fail. Applications may be arbitrary but their implementation certainly would not.

Regards
Anders

On 2016-05-09 19:31, Andrew Swan wrote:
>
> On Sun, May 8, 2016 at 10:25 PM, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>
>>       You have reasonable points about the limits of the current security model for native messaging, but I think these limits are well understood and that the system implemented in Chrome represents current best practices with those limits in mind.
>
>     Well, off-list contacts with Google core security folks indicate something else.  Native Messaging isn't considered as a "solution", it is rather a "last resort" for people who have made huge investments in the previous extension mechanism.  That is, that the deployment scheme for Native Messaging is awkward, is (according to the same sources) only good, because it /discourages people from developing new native extensions/.
>
>
> I think we have a pretty big disconnect here and I suspect that it stems from not having agreement on the purpose/goals of native messaging.  If you define the purpose of native messaging as "provide a convenient way to safely run arbitrary native code" then I can certainly understand why you would be disappointed with the current capabilities.  But the actual goals are much more modest. I'm not sure how to really state them concisely but something like "provide a controlled way to communicate with native applications that fits within the limits of the existing security/trust model for native applications".
>
> To state the obvious, meeting the first goal is really part of a larger unsolved problem and trying to solve that large problem is extraordinarily ambitious.  I don't mean to dissuade you from pursuing it, but it is quite removed from the much more modest, pragmatic goals of the native message standardization project.
>
>     It is also pretty obvious that an extension scheme using native code where the native code is unknown by the publisher (Google), isn't really targeting the mass market.  That there's no cryptographic binding between the extension and the native executable indirectly tells the same.
>
>
> I don't agree with this at all.  Password managers are a great example of widely used extensions that can use native messaging today.  I don't really understand the first sentence above,.  I don't know if Google has a relationship with the vendors of password management applications, but the native messaging mechanism doesn't require them to have a relationship and I think that is desirable and worth maintaining.
>
> As for "cryptographic bindings", the native manifest declares what extensions are allowed to access it.  In Firefox, an extension is digitally signed, so the native executable can trust that the only extensions that will be allowed to communicate with it are those that the author has explicitly authorized.  There is not currently a mechanism for verifying in the opposite direction (ie for the extension to verify the executable it is communicating with) but an attacker who could replace the native executable has a level of access that they could use to initiate many other attacks.  Nevertheless, there is a proposal to use code signing facilities from the underlying platforms to allow extensions to verify native executables to cover this scenario.
>
> -Andrew
>