Re: Native Messaging (Was: Core API Proposal)

Okay.

To be frank, I'm not sure exactly what you're advocating with respect to
the proposed effort to standardize native messaging (the original topic of
this thread).  Is it fair to say that you don't think the proposed effort
is likely to be useful but that you don't object to it moving ahead?  I'm
not trying to put words in your mouth, please correct me if I've got it
wrong, but I'd like to have this effort proceed and I think there's some
uncertainty lingering over it as a result of this thread...

-Andrew


On Mon, May 9, 2016 at 11:26 AM, Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

> 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>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
>
>
>