Re: Web2Native Bridge emulator

Anders,

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. I
   doubt that the browser vendors will jump at this as my experience tells me
   that part of keeping the browser secure is solving small problems one at a
   time and eliminating side-effects.
   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. 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.
   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 and I don't need to know what technology stack the user
   has behind the API to support my request.

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?

Adrian

On 26 June 2015 at 15:18, Anders Rundgren <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>>
>> 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
>>
>>
>>
>
>