Re: Native Messaging (Was: Core API Proposal)

Anders,

This has been an interesting debate but it seems a little misplaced here.
If your goal is to create APIs that are available to arbitrary content
pages, then the browser extensions working group isn't the right place.  If
your goal is to create a cross-platform OS-level standard, then I don't
think anything within the W3C is really the right place!  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.

Your proposal for developing a new "vetting" infrastructure is ambitious,
are you arguing that we should not standardize something for browser
extensions right now pending that effort?  I can tell you that we (Mozilla)
are not going to wait for any of those efforts before we implement native
messaging, and I think that having a cross-browser standard for what we can
do today would be a good thing for extension developers.  If your efforts
succeed and today's standards become obsolete in favor of new content APIs
with your new native application security review system, great, but we
can't stand by and wait for that.

-Andrew


On Sun, May 8, 2016 at 8:33 AM, Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

> Hi Rob,
> That was a lot!
>
> I think I limit my comments to what I consider the core.
>
> Security:
> ---------
> > if users install the native app, which trusts the extension
> > via allowed_origins), then the user trusts that the native
> > app and its corresponding extension behaves well.
>
> My idea was that "Web callable" native applications would require vetting
> rather than having users perform conscious trust decisions.
> This part of the plot should be pretty much independent of the actual
> native extension scheme, be it services on "localhost" or Native Messaging.
> Installation, vetting (including associated policies), and developer mode
> would be up to each (platform) vendor to decide.
>
> Packaging and deployment:
> -------------------------
> I was rather hoping for a solution where the Web call extension mechanism
> becomes a part of the Operating System.
> In such a scheme, Web callable applications wouldn't be featured in
> extension galleries; they'd rather belong to the platform "AppStore".
> Browsers (including third-party dittos) would only require a moderate
> upgrade to support this capability.
>
> API ease of use:
> ----------------
> If your goal is using Native Messaging from ordinary Web pages, Chrome's
> variant gets a bit awkward since you must send messages in two steps.
>
> Code isolation:
> ---------------
> AFAICT, Chrome's browser-injected extension code run in the
> web-application space which for "unlimited" extensions like mine, seems
> likely to create clashes since the injected code must be unconditionally
> loaded.
>
> Market:
> -------
> There's virtually no end to what kind of applications that could benefit
> from *some kind of* native mode extension scheme. From cloud services like
> GitHub to Payments.
>
> Regards,
> Anders
>
>
>
> On 2016-05-08 16:21, Rob Wu wrote:
>
>> 2016-05-04 20:14 GMT+02:00 Anders Rundgren <anders.rundgren.net@gmail.com
>> <mailto:anders.rundgren.net@gmail.com>>:
>>
>>
>>     On 2016-05-04 14:38, Rob Wu wrote:
>>     > 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
>>
>>     My primary (and rather big) "problem" with Chrome's native messaging
>> is that such an
>>     extension consist of two separate software packages with no apparent
>> (or secure) binding.
>>
>>
>> There is a binding: Only extensions in the allowed_origins list can use
>> the native app.
>> I re-iterate my question, can you state objective
>> advantages/disadvantages of your proposal over native messaging?
>>
>>
>>         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.
>>
>>     After installing the by Google "approved" Web2Native Bridge
>> extension, no such limitations exist:
>>     https://chrome.google.com/webstore/search/web2native
>>
>>
>> The extension itself cannot do anything harmful. Users have to install
>> the native component before anything bad could happen.
>> if users install the native app, which trusts the extension (via
>> allowed_origins), then the user trusts that the native app and its
>> corresponding extension behaves well.
>>
>> If the native messaging component were to be bundled with the add-on,
>> manual review (like Firefox' add-on gallery) is required, because it's then
>> the galleries responsiblity to make sure that the offered
>> apps/extensions/add-ons are safe.
>>
>> Manual review is not infallible, and mistakenly granting approval is not
>> specific to nativeMessaging - in fact, your proposal has the same problem
>> in the unspecified "vetting infrastructure".
>>
>>
>>             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.
>>
>>     You're right.  What my demo program shows is that the "approval"
>> process is insufficient.
>>     And if it actually did work what would the result be?
>>
>>
>> If the review process did work, then in terms of security the result is
>> equivalent to extensions + properly functioning review process. To make a
>> fair comparison, either assume that both review processes are flawed, or
>> that they're both doing well.
>>
>>
>>         Compared to native messaging, I think that your Web2native
>> proposal is
>>         1) more complex (new infrastructure for vetting, a new "AppStore")
>>
>>
>>     It requires
>>     - a new infrastructure for wetting
>>     - an OS-dependent solution for adding needed meta-data to executables.
>>
>>     But it should (hopefully) not require a new "AppStore"
>>
>>
>> New infrastructure for vetting is expensive. Let's think more concretely
>> what this would look like. After the vetting, there will be a cryptographic
>> signature that attests that the application is vetted and that it may run.
>> How is this any better than signed add-on packages that are only published
>> by the extension galleries once approved?
>>
>>     Yes, this is a lot of work.  Unfortunately there's no other way if we
>> are
>>     talking about a "solution" rather than the current "workaround".
>>
>>
>> Can you elaborate, in what sense is native messaging a "work-around" and
>> your proposal a "solution"? What problems does your proposal solve that is
>> not already addressed by native messaging (with reasonable trade-offs)?
>>
>>
>>
>>     Such a solution would also (depending on platform vendor
>> cooperativeness...)
>>     also work with alternative browsers.
>>
>>
>> Only if they implement Web2Native and trust the vetting process.
>> Different platforms have different ideas about the kind of acceptable
>> programs. For instance, YouTube downloaders are allowed in Firefox but not
>> in Chrome.
>>
>>
>>         2) not more secure (native messaging requires user consent
>> through an install-time permission dialog)
>>
>>
>>     The *emulator version* of the Web2Native Bridge "inherits" the
>> following from Native Messaging
>>     - No native application vetting infrastructure
>>     - No HTTPS information
>>     - No site-blocking support and associated administration
>>
>>     in addition to injecting JavaScript in every web-page visited!
>>
>>
>> You didn't refute my claim that native messaging is at least as secure as
>> Web2Native. Maybe I was not clear - as an example, I showed that native
>> messaging has an extra requirement that Web2Native does not have, namely an
>> install-time permission dialog.
>>
>> The four things that you mentioned are not a limitation of native
>> messaging, but rather your specific implementation. If you had enough time,
>> you could implement all of the four things on top of native messaging to
>> achieve what you want. And this is my main point: Except for the
>> inconvenience of separately installing native programs, native messaging is
>> a reasonably secure primitive that can be used as a foundation for other
>> programs (e.g. your Web2Native bridge). If you want to get your proposal to
>> succeed, you have to demonstrate that its added complexity is warranted by
>> its merits (or even better: that it does not add complexity).
>>
>>
>>         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.
>>
>>     If the IPC mechanism for some reason would need to change, I don't
>> think applications
>>     should be affected.  The Web2Native Bridge emulator [primitively]
>> abstracts the channel:
>>
>> https://github.com/cyberphone/web2native-bridge/blob/master/proxy/src.java/org/webpki/w2nbproxy/StdoutJSONPipe.java
>>
>>
>> I showed the possiblity of adding new protocols *when necessary* (e.g. if
>> JSON is an ill-suited transport method). Adding a new protocol does not
>> change existing ones (currently "stdio" is the only protocol). Your Java
>> implementation abstracts by wrapping the message in another packet, this is
>> a way to use the existing protocol without changes.
>>
>>
>>         IMO, the nativeMessaging API is well-designed
>>
>>
>>     The API (and associated "config") is pretty awkward to master
>> compared to the Web2Native Bridge:
>>     https://github.com/cyberphone/web2native-bridge#api
>>
>>
>>
>> The client API doesn't look that different from native messaging:
>> https://developer.chrome.com/extensions/nativeMessaging#native-messaging-client
>> I agree that the config is inconvenient for developers (and users who
>> need to install both components before they can use it), and that is where
>> this CG might bring some improvements.
>>
>>         and receptive to enhancementsif ever needed.
>>
>>
>>     Great, can we have caller security context?
>>
>>
>> Although not documented, the origin of the caller is already passed as an
>> argument to the native application (
>> https://chromium.googlesource.com/chromium/src/+/c963c714c99f34bd80b392d9896ca9cecd66fb6d/chrome/browser/extensions/api/messaging/native_process_launcher.cc#192
>> ).
>> But by receptive to enhancement, I was referring to the flexible stdio
>> protocol and the ability to define new protocols if needed.
>>
>>
>>         The main issue with using native messaging is deploying it, since
>> users
>>
>>     > have to separately install an extension and native app.
>>
>>     Indeed. And then there is the vetting...
>>
>>
>> ... which can be integrated in extension stores and don't have to be a
>> separate infrastructure. See my previous comment about the single
>> cryptographic signature, and the deducation that the existing
>> infrastructure suffices.
>>
>>
>>         If you want to standardize native messaging,
>>
>>
>>     I'm not alone, this is one of the goals with the browserext CG as
>> well.
>>
>>
>> "you" as in whoever who wants to turn a native messaging API into a
>> standard that gets implemented by more than one vendor.
>>
>>
>>         I suggest taking the nativeMessaging API as-is
>>
>>     > and specify a standard way to include the binary in the extension
>> package.
>>
>>     I think you should confront Google with this proposal, I'm not sure
>> they would
>>     be entirely happy with it but I could be wrong.
>>
>>
>> If we demonstrate that the proposal is *at least as secure* and simpler
>> than the status quo, then I think that there is a reasonable chance of
>> adoption. It has to not only be simple for devs/users, but also for
>> (automated) reviewers in the Chrome Web Store.
>>
>>     BTW, Chrome for Android does not support any extensions AFAIK.
>>
>>
>> If Chrome Mobile doesn't support extensions, the odds of getting
>> Web2Native accepted is even smaller.
>> The closest alternative to running native code is Google's own
>> NativeClient, and that is not supported either.
>>
>>
>>         Editors of extension galleries MUST review sources for the binary
>> and confirm
>>
>>     > that the native component behaves well.
>>
>>     Apple won't rely on that, and neither would I.
>>
>>
>> Apple is the editor of their extension gallery ("editor" as in "the one
>> who is in charge of the store"), so they do rely on the review process
>> (otherwise they could as well close down the store).
>> If you refuse to accept that the review process is reasonable, then your
>> own proposal also falls down because its security requires a properly
>> functioning vetting process, which is similar if not identical to the
>> app/extension review process.
>>
>>     > so the use of native messaging should not be encouraged unless
>> absolutely necessary.
>>
>>     Unfortunately it is currently not possible creating a useful Web
>> payment systems
>>     for mobile phones (aka Wallets) so there will be a gazillion of such
>> extensions.
>>
>>
>> And if Web2Native were to be implemented, then there will be "a gazillion
>> of such apps"...
>> Since your main objective is getting support for web payment systems in
>> browsers, maybe you should join the Web Payments CG?
>>
>
>