Re: Web2Native Bridge emulator

On 26 June 2015 at 20:29, Anders Rundgren <anders.rundgren.net@gmail.com>
wrote:

> 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.
>
>
Then you addressing a very different use case to the web payments work. As
a merchant looking to call out to a browser API to initiate payment
negotiation with my customer I don't expect to know what wallet software he
has installed any more than a Web app that is looking for location info
should need to know what GPS hardware the user has.

The generic use case is solved by specific APIs for that use case where the
technology stack behind the API (in this case a wallet) is not important.

Why the Web2Native bridge has value for developers looking to solve interop
problems that are not yet clearly defined and who don't want to be
constrained by the browser vendors willingness to implement a new API. That
said I'm not sure I see the appeal for a browser vendor of something that
is just a new attack vector to have to consider in security analysis.


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