Re: Native Messaging (Was: Core API Proposal)

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?

Received on Sunday, 8 May 2016 16:30:38 UTC