Re: Web2Native Bridge emulator

On 2015-06-26 16:05, Adrian Hope-Bailie wrote:
> Anders,

Hi Adrian,
This is a complex topic so a TL;DR warning in probably needed...

> The Web2Native work is very well done however I think there are three
 > challenges you will face in seeing it standardized.
>
>  1. It does not address a specific problem. It is simply an admission
 >      that there are many problems that can be solved by having a bridge
 >      to native applications so let's just open that up and see what happens.

As an individual developer I have hardly any other option, do i?

Anyway, I do have contacts with other parties using Native Messaging so
it wasn't developed in pure vacuum.  The next step is creating a fairly
advanced Web-invoked Wallet for public testing and concept verification.


 >      I doubt that the browser vendors will jump at this

Correct. They removed ActiveX and NPAPI without considering the MILLIONS
of users depending on such solutions.


>      as my experience  tells me that part of keeping the browser secure is
 >      solving small problems one at a time and eliminating side-effects.

I'm not sure what "small problems" you think needs to be solved except the
stuff you mention below:


>  2. It is very similar to simply addressing a locally running application listening
 >     on a custom port which is currently the method used by many native apps to
 >     communicate with their Web apps.

Yes, which means that the core concept (invoking an application *outside* of the browser),
including security model is de-facto already established.


>     I know there is talk of breaking this but
 >     I think the security issues will be addressed there before a whole new hole
 >     is opened up to do the same thing.

See last part of this message.

I'm not aware of a single security problem with W2NB except that bad native
applications can screw up everything which is why vetting is a requirement.

I would be *extremely happy* if somebody else performed a security review.


>  3. Your native apps are only addressable by name not by function. The benefit
 >     of standard browser APIs is that as the Web app author I simply call out
 >     to the API

The difference in practice is fairly small.  My existing public WebCrypto++
demo (https://mobilepki.org/WebCryptoPlusPlus) uses this concept; it is the
*messages* that contain the actual "meat".


>     and I don't need to know what technology stack the user has
 >     behind the API to support my request.

This is not how I intend this system to be used. An application called
"com.mybank.pay.v1" would (should) be identical with the respect to the
calling Web application on all platforms where it is implemented.


> I think a valuable contribution to solving this problem would be figuring out
 > a way to secure a standard http/websocket connection to a service running on
 > localhost in a way that deals with the vulnerabilities currently at the heart
 > of Chrome's threats to shut this down.
>
> Do you have any thoughts on how this may be done?

No, I don't and don't intend to spend any time on it either because the
Native Messaging concept as featured in Chrome is simpler to secure
(OS-based IPC and process isolation mechanisms) and provides a lot more
information to the called application including caller HTTPS data and
Window handle to invoking page.  The latter is missing in the emulator
since Chrome's [rather prototypic] implementation doesn't provide this.

Anders

>
> Adrian
>
>
> On 26 June 2015 at 15:18, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>
>     On 2015-06-26 13:55, UniDyne wrote:
>
>         This is very interesting.
>
>
>     Thanx!
>
>         I assume the proxy itself would be provided by the browser manufacturer.
>
>     > Assuming the security / vetting infrastructure could be built around the
>     > native bits, who provides them? Is it payment processors?
>
>     The vetting would (IMO) build on existing schemes like Apple's for AppStore.
>     The vetting process would only "guarantee" (within limits) that applications
>     do not violate platform integrity and user privacy as well as conforming to
>     the store's policy regarding content etc.
>
>     It should preferably NOT be possible publishing an application without some kind
>     of proof of ownership to the exposed name of the application ("com.mybank.pay.v1").
>
>
>         User's banks? Both?
>
>
>     The native applications would be supplied to the applicable store's distribution
>     center in (almost) the same way as today but this is really up to each vendor
>     to decide.
>
>     A core idea is enabling third-parties creating powerful extensions to browsers
>     as an alternative to lengthy Web API standardization processes for applications
>     that the platform/browser vendors may neither be interested nor competent in.
>
>     Yes, this scheme would allow closed source web applications. Although not exactly
>     my cup of tea, some people have indeed expressed such interests...and it is vital
>     listening to the market :-)
>
>
>         Does the user have a choice of native extension like  they have a choice of search provider?
>
>
>     Technically possible, implementation-wise less likely. Apple, Google or Microsoft
>     do not offer any alternative AppStore's.
>
>     However, a possibility would be that the invocation could target multiple applications like
>
>        navigator.nativeConnect(["com.mybank.pay.v1","org.freebank.pay"]).then(function(port)...
>
>     and then the system/user could offer a choice.  If these application have identical
>     Web-level interface everything is OK.  If not, the actual application would have to
>     be returned through the "port" object.  This part obviously requires a bit more
>     work/thinking/testing.
>
>     Anders
>
>
>
>
>         On Wed, Jun 24, 2015 at 11:24 PM, 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>>> wrote:
>
>              For those who (like me) do not regard browser vendors as the most logical
>              implementers of Web Payment systems (and Credential Management schemes...),
>              here is an alternative that can be tested on Windows, Ubuntu and Mac:
>         https://github.com/cyberphone/web2native-bridge
>
>              I'm in the process of writing a Wallet but that's non-trivial, so you have to live with
>              a simple chat-like application which though shows the technology in its purest form.
>
>              Comments are very welcome!
>
>              Cheers,
>              Anders
>
>
>
>
>

Received on Friday, 26 June 2015 18:29:38 UTC