Re: Native Messaging (Was: Core API Proposal)

2016-05-04 8:44 GMT+02:00 Anders Rundgren <anders.rundgren.net@gmail.com>:

> Hi Guys,
>
> This is another and implemented proposal for Native Messaging which you
> can test if you want.
>
> It is based on the idea that a native extension is a standard executable
> augmented
> with meta-data indicating for the Browser/OS platform that it is intended
> (maybe even
> certified) for being callable from the "open Web":
>
> https://github.com/cyberphone/web2native-bridge
>
> That is, IMO, native messaging should be separated from "in-browser"
> extensions.
>

Currently only Chrome extensions and apps can use nativeMessaging because
only the chrome-extension:-scheme is accepted in the allowed_origins list.
What advantages / disadvantages does your proposal have over using
nativeMessaging + allowing https: in the allowed_origins list? For the
syntax, see
https://developer.chrome.com/extensions/nativeMessaging#native-messaging-host

Technically, it is possible to offer the
chrome.runtime.connectNative/sendNativeMessage to web pages. I guess that
this was not allowed yet because of security concerns: Extensions can be
reviewed and approved/rejected, there is no such review process for web
pages.

A security review of Google's take on this matter:
> https://lists.w3.org/Archives/Public/public-webappsec/2015Oct/0071.html


The main claim of your "security review" is that a native program can
enable any program to execute native code (without asking for permission)
because there is no vetting what a native extension actually does.
This scenario occurs when all of the following have happened:
1) The user installs a malicious native program.
2) The malicious native program is registered as a native messaging host.
3) The user installs an extension that uses (Chrome's) native messaging API.
4) Web pages can use the native code execution capabilities if the
extension acts as a proxy between the web page and native program.

Step 1 and 2 requires the user to put malicious files in specific
directories, and step 3 requires explicit user consent via a permission
dialog upon installation.
If a user went through steps 1 and 2, odds are that an attacker can already
run arbitrary code (and compromise the user's computer). The presence of
the native messaging API does not degrade the security in this respect.

Now, how does your Web2Native system work (based on the Github page and
web2native-bridge.pdf)?
1) The user installs a vetted native program (vetted = complete new
infrastructure, TBD).
2) As a part of the installation, a the entry point is stored in
proxy/install/apps/
3) Web pages can use the native code execution capabilities if the
Web2Native proxy allows it.

Compared to native messaging, I think that your Web2native proposal is
1) more complex (new infrastructure for vetting, a new "AppStore")
2) not more secure (native messaging requires user consent through an
install-time permission dialog)

The Web2Native proposal also includes unnecessary parameters such as
"coordinates of the calling web page". If an application needs it, they can
include it in the message. By design, the nativeMessaging API of Chrome may
support more than one communication protocol (as defined in the native
messaging host manifest). So if it ever becomes necessary to add this kind
of information in the protocol, just define a new protocol.

IMO, the nativeMessaging API is well-designed and receptive to enhancements
if ever needed  The main issue with using native messaging is deploying it,
since users have to separately install an extension and native app. If you
want to standardize native messaging, I suggest taking the nativeMessaging
API as-is and specify a standard way to include the binary in the extension
package. Editors of extension galleries MUST review sources for the binary
and confirm that the native component behaves well. This is a burden for
reviewers, so the use of native messaging should not be encouraged unless
absolutely necessary.

Kind regards,
 Rob
 https://robwu.nl