Re: Native Messaging (Was: Core API Proposal)

On 2016-05-09 06:24, Andrew Swan wrote:
>
> 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.

I see.  IMO, in-browser extensions (plugins) and calling external applications do not have that much in common; they just happen to have been lumped together in Chrome desktop because it was easy to do.


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

What I described was simply a model for how (my take on) Native Messaging /could (preferably) be implemented/.  I think it will be difficult continuing the scheme used for desktops in Android (=my primary interest).  Google have (AFAIK) not said a word about what they plan regarding extensions for Android.


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

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.


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

Of course you can standardize such a thing.  However, it seems like a pretty large project and if you do not reach a common "ExtStore" I think it may prove to be a waste of time.

An OS-level Native Messaging scheme like I outlined OTOH could work out-of-the-box with third-party browsers.


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

That's something I fully understand.

What's really missing in this discussion are the platform owners view on this topic.

Anders


>
> -Andrew
>
>
> On Sun, May 8, 2016 at 8:33 AM, Anders Rundgren <anders.rundgren.net@gmail.com <mailto: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> <mailto: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?
>
>
>