info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Intent to implement: Web2Native Bridge
124 views
Skip to first unread message
Anders Rundgren
Nov 29, 2016, 12:10:18 PM11/29/16
to
There are virtually tons of developers out there using Android Intents to start "Apps" from the Web.
However, this mechanism sucks big-time since:
1. It leaves the invoking Web page in an "orphaned" state
2. There's no way to "talk back" to the invoked Web page
3. There's no Web page security context available to invoked "App"
4. There's no App/Web life-cycle control
The Web2Native Bridge does all that:
https://github.com/cyberphone/web2native-bridge#api
Unfortunately (or maybe you guys think fortunately) I will most likely implement this in Chromium since there is more activity in that channel.
Mozilla have already focused on a similar concept which I doubt will ever be supported in Android: https://browserext.github.io/native-messaging/
In Android Apps does a better job than "in-browser" extensions.
Anders
However, this mechanism sucks big-time since:
1. It leaves the invoking Web page in an "orphaned" state
2. There's no way to "talk back" to the invoked Web page
3. There's no Web page security context available to invoked "App"
4. There's no App/Web life-cycle control
The Web2Native Bridge does all that:
https://github.com/cyberphone/web2native-bridge#api
Unfortunately (or maybe you guys think fortunately) I will most likely implement this in Chromium since there is more activity in that channel.
Mozilla have already focused on a similar concept which I doubt will ever be supported in Android: https://browserext.github.io/native-messaging/
In Android Apps does a better job than "in-browser" extensions.
Anders
Nicholas Alexander
Nov 29, 2016, 4:01:38 PM11/29/16
to Anders Rundgren, dev-platform
Hi Anders,
On Tue, Nov 29, 2016 at 9:10 AM, Anders Rundgren <
anders.ru...@gmail.com> wrote:
> There are virtually tons of developers out there using Android Intents to
> start "Apps" from the Web.
>
Aye, and Firefox does support this custom URI scheme.
> However, this mechanism sucks big-time since:
> 1. It leaves the invoking Web page in an "orphaned" state
> 2. There's no way to "talk back" to the invoked Web page
> 3. There's no Web page security context available to invoked "App"
> 4. There's no App/Web life-cycle control
>
> The Web2Native Bridge does all that:
> https://github.com/cyberphone/web2native-bridge#api
I took a look at this and don't yet see how this translates to Android. It
all seems very Chrome OS specific: "Applications callable by the Web2Native
Bridge emulator *must* be written in Java and stored in a for the purpose
dedicated directory."
Is your intention to define a new specification for how an Android App
advertises this capability and how the browser connects to it? (Android
Intents, an AIDL and handshake protocol, etc...) This would be
interesting; it's similar in spirit to the Chrome Custom Tabs work, which
goes in the opposite direction: it makes Apps have better entry into the
browser (where-as you want content in the browser to have better entry into
a companion App).
Unfortunately (or maybe you guys think fortunately) I will most likely
> implement this in Chromium since there is more activity in that channel.
>
I never think it's fortunate when folks passionate enough to implement a
thing don't implement under the Mozilla umbrella! I can provide some
guidance on doing this in Firefox for Android, if you'd like to try it
under our umbrella. I can't speak to things like ship criteria and release
schedules, though :(
As a bizarre "Mozilla bonus point", I bet you can do this in a bootstrapped
extension using the essentially undocumented "Java addons" feature! It's
100% non-obvious how to use it, but you can add a classes.dex to a Firefox
addon and load it using a Java class loader. See
https://dxr.mozilla.org/mozilla-central/source/mobile/android/javaaddons/java/org/mozilla/javaaddons/JavaAddonInterfaceV1.java
and the test at
https://dxr.mozilla.org/mozilla-central/source/mobile/android/tests/browser/chrome/test_java_addons.html,
which appears to be still running in our automation. Using this, you could
have your extension inject the `navigator.nativeConnect` method into the
content context (at least I think this is possible, I did it once -- see
https://github.com/ncalexan/bootstrapped-webapi-skeleton -- but I think
this approach may no longer work) and then use a Java addon to handle
proxying out to your test application, either using Intents or binding a
Service or whatever. Wild stuff!
But honestly, you might find it easier to hack up Fennec, since Fennec +
extensions + a new Web API + Java addons probably requires you to be a
Fennec hacker in the first place...
Mozilla have already focused on a similar concept which I doubt will ever
> be supported in Android: https://browserext.github.io/native-messaging/
> In Android Apps does a better job than "in-browser" extensions.
>
Is this the same as
https://mail.mozilla.org/pipermail/firefox-dev/2016-July/004461.html?
In general, I think there are really hard security and permission questions
that need to be raised and answered around this work. For example, it's a
fundamental tenet of "the Web" that sites are isolated. How does one
ensure that origin "foo.com" can only access "com.foo.application"? What
does this even mean on Android, where the first App with an Android package
name is the winner (leading to wild security holes, some of which I have
had to fix in Fennec), regardless of who publishes the App? These are hard
questions that can't be punted in a shipping product. (Of course, they can
be punted in an experiment or tech demo!)
Nick
On Tue, Nov 29, 2016 at 9:10 AM, Anders Rundgren <
anders.ru...@gmail.com> wrote:
> There are virtually tons of developers out there using Android Intents to
> start "Apps" from the Web.
>
> However, this mechanism sucks big-time since:
> 1. It leaves the invoking Web page in an "orphaned" state
> 2. There's no way to "talk back" to the invoked Web page
> 3. There's no Web page security context available to invoked "App"
> 4. There's no App/Web life-cycle control
>
> The Web2Native Bridge does all that:
> https://github.com/cyberphone/web2native-bridge#api
all seems very Chrome OS specific: "Applications callable by the Web2Native
Bridge emulator *must* be written in Java and stored in a for the purpose
dedicated directory."
Is your intention to define a new specification for how an Android App
advertises this capability and how the browser connects to it? (Android
Intents, an AIDL and handshake protocol, etc...) This would be
interesting; it's similar in spirit to the Chrome Custom Tabs work, which
goes in the opposite direction: it makes Apps have better entry into the
browser (where-as you want content in the browser to have better entry into
a companion App).
Unfortunately (or maybe you guys think fortunately) I will most likely
> implement this in Chromium since there is more activity in that channel.
>
thing don't implement under the Mozilla umbrella! I can provide some
guidance on doing this in Firefox for Android, if you'd like to try it
under our umbrella. I can't speak to things like ship criteria and release
schedules, though :(
As a bizarre "Mozilla bonus point", I bet you can do this in a bootstrapped
extension using the essentially undocumented "Java addons" feature! It's
100% non-obvious how to use it, but you can add a classes.dex to a Firefox
addon and load it using a Java class loader. See
https://dxr.mozilla.org/mozilla-central/source/mobile/android/javaaddons/java/org/mozilla/javaaddons/JavaAddonInterfaceV1.java
and the test at
https://dxr.mozilla.org/mozilla-central/source/mobile/android/tests/browser/chrome/test_java_addons.html,
which appears to be still running in our automation. Using this, you could
have your extension inject the `navigator.nativeConnect` method into the
content context (at least I think this is possible, I did it once -- see
https://github.com/ncalexan/bootstrapped-webapi-skeleton -- but I think
this approach may no longer work) and then use a Java addon to handle
proxying out to your test application, either using Intents or binding a
Service or whatever. Wild stuff!
But honestly, you might find it easier to hack up Fennec, since Fennec +
extensions + a new Web API + Java addons probably requires you to be a
Fennec hacker in the first place...
Mozilla have already focused on a similar concept which I doubt will ever
> be supported in Android: https://browserext.github.io/native-messaging/
> In Android Apps does a better job than "in-browser" extensions.
>
https://mail.mozilla.org/pipermail/firefox-dev/2016-July/004461.html?
In general, I think there are really hard security and permission questions
that need to be raised and answered around this work. For example, it's a
fundamental tenet of "the Web" that sites are isolated. How does one
ensure that origin "foo.com" can only access "com.foo.application"? What
does this even mean on Android, where the first App with an Android package
name is the winner (leading to wild security holes, some of which I have
had to fix in Fennec), regardless of who publishes the App? These are hard
questions that can't be punted in a shipping product. (Of course, they can
be punted in an experiment or tech demo!)
Nick
Anders Rundgren
Nov 30, 2016, 5:40:40 AM11/30/16
to
On Tuesday, November 29, 2016 at 10:01:38 PM UTC+1, Nicholas Alexander wrote:
Hi Nick,
Many thanks for your elaborate comments!
If we begin with security, Android already allows Web-sites to invoke apps which they have no specific relation to using the custom URI scheme. I don't see that the ability of "talking back" to the calling Web page would introduce new vulnerabilities. I haven't noted any web-site registry involved in this operation either, you do a one-time grant for selecting browser (if needed) and that's it. The only quirk seems to be that the invocation must be related to a user action.
Anyway, the *long-term* goal for this API is that Web-enabled Apps should be *vetted* for this kind of usage which also involves changes in "AppStores" and OSes to work. The need for vetting may also depend on what local resources an App access. This part will likely be vendor-and OS-specific.
A security review of mine regarding the Google/Mozilla/Microsoft take on the matter:
https://lists.w3.org/Archives/Public/public-webappsec/2015Oct/0071.html
If you look into the W2NB docs it says it is an "emulator", not the real deal. The application ID is just a proposal which though should fit Android pretty well.
Now over to the actual implementation...
I see two possibilities, one which is more of a PoC allowing people testing the core concept on a standard Android phone. It is still not clear to me if this is technically feasible :-( Hopefully the links you provided give some answers. I'm also looking into Web Payment API which I (believe) does quite similar things albeit in a very specific manner. If this doesn't work I'm will try another route which I cannot write about on a public list.
If Mozilla could consider giving me some support, I would be more than happy to build on Firefox!
The Web2Native Bridge is the core of a more ambitious effort which among many things is about transcending on-line payments from the pitiful state it has been in the last 20 years or so. Well, Google and Apple have already done that, but I'm targeting the other 99.99999% who don't have a platform they can update whenever there's a need.
Best
Anders
Hi Nick,
Many thanks for your elaborate comments!
If we begin with security, Android already allows Web-sites to invoke apps which they have no specific relation to using the custom URI scheme. I don't see that the ability of "talking back" to the calling Web page would introduce new vulnerabilities. I haven't noted any web-site registry involved in this operation either, you do a one-time grant for selecting browser (if needed) and that's it. The only quirk seems to be that the invocation must be related to a user action.
Anyway, the *long-term* goal for this API is that Web-enabled Apps should be *vetted* for this kind of usage which also involves changes in "AppStores" and OSes to work. The need for vetting may also depend on what local resources an App access. This part will likely be vendor-and OS-specific.
A security review of mine regarding the Google/Mozilla/Microsoft take on the matter:
https://lists.w3.org/Archives/Public/public-webappsec/2015Oct/0071.html
If you look into the W2NB docs it says it is an "emulator", not the real deal. The application ID is just a proposal which though should fit Android pretty well.
Now over to the actual implementation...
I see two possibilities, one which is more of a PoC allowing people testing the core concept on a standard Android phone. It is still not clear to me if this is technically feasible :-( Hopefully the links you provided give some answers. I'm also looking into Web Payment API which I (believe) does quite similar things albeit in a very specific manner. If this doesn't work I'm will try another route which I cannot write about on a public list.
If Mozilla could consider giving me some support, I would be more than happy to build on Firefox!
The Web2Native Bridge is the core of a more ambitious effort which among many things is about transcending on-line payments from the pitiful state it has been in the last 20 years or so. Well, Google and Apple have already done that, but I'm targeting the other 99.99999% who don't have a platform they can update whenever there's a need.
Best
Anders
Anders Rundgren
Dec 1, 2016, 1:03:12 AM12/1/16
to
I believe both the Android Intent solution and the Google/Mozilla/Microsoft take on native messaging are vulnerable to phishing attacks which has bearing on authentication solutions. That is, the unavailability of a security context to the called application represents a problem including the possibility simply lying to the end-user.
Nicholas Alexander
Dec 1, 2016, 3:51:36 PM12/1/16
to Anders Rundgren, dev-platform
On Wed, Nov 30, 2016 at 2:40 AM, Anders Rundgren <
anders.ru...@gmail.com> wrote:
> On Tuesday, November 29, 2016 at 10:01:38 PM UTC+1, Nicholas Alexander
> wrote:
> Hi Nick,
> Many thanks for your elaborate comments!
>
Heh, that message kept growing and probably could be a blog post when it's
anders.ru...@gmail.com> wrote:
> On Tuesday, November 29, 2016 at 10:01:38 PM UTC+1, Nicholas Alexander
> wrote:
> Hi Nick,
> Many thanks for your elaborate comments!
>
all done :)
> If we begin with security, Android already allows Web-sites to invoke apps
> which they have no specific relation to using the custom URI scheme. I
> don't see that the ability of "talking back" to the calling Web page would
> introduce new vulnerabilities. I haven't noted any web-site registry
> involved in this operation either, you do a one-time grant for selecting
> browser (if needed) and that's it. The only quirk seems to be that the
> invocation must be related to a user action.
>
fooled: the invocation must be in response to a user action. I think the
invoked App could silently process that Intent without indicating anything
to the user, so it would be up to the OS to ensure the user knows *which*
App is handling the action. I've never used this flow so I don't know if
that happens, or how easy it would be to spoof.
> Anyway, the *long-term* goal for this API is that Web-enabled Apps should
> be *vetted* for this kind of usage which also involves changes in
> "AppStores" and OSes to work. The need for vetting may also depend on what
> local resources an App access. This part will likely be vendor-and
> OS-specific.
>
certainly vets the URL space associated to an App -- but you might be able
to do it at the browser level too. It seems like what we're trying to do
is extend the concept of "secure origin" to "secure App". That is, we need
a dictionary between {SSL certifacte, origin, ...} and {App ID, App
signature, ...}. If you think of Chrome's Origin Trials, this might be
similar: an origin could register an App ID *and* App signature that the
browser could verify before opening a channel to the App, for instance. In
fact, this could just be part of the JS API you propose, which is already
extremely Android specific...
In general, my point remains: the security model of the Web is relatively
well understood, and users trust it. The security model of Apps is very
poorly understood by users and I claim there is no "informed consent". I
would like the many, many people who have thought about this problem
involved before we punch a bi-directional hole between these two models.
After all, isn't the Canonical Use Case to provide login credentials
between Web and App so you get a seamless experience with a single
sign-on? That requires some level of trust between the two models.
> A security review of mine regarding the Google/Mozilla/Microsoft take on
> the matter:
> https://lists.w3.org/Archives/Public/public-webappsec/2015Oct/0071.html
>
>
> If you look into the W2NB docs it says it is an "emulator", not the real
> deal. The application ID is just a proposal which though should fit
> Android pretty well.
>
> Now over to the actual implementation...
>
> I see two possibilities, one which is more of a PoC allowing people
> testing the core concept on a standard Android phone. It is still not
> clear to me if this is technically feasible :-(
technically feasible :) That doesn't mean it's easy, and definitely
doesn't mean that it's a good idea.
> Hopefully the links you provided give some answers.
> I'm also looking into Web Payment API which I (believe) does quite
> similar things albeit in a very specific manner.
implementation instructive at this time, but more power to you if I am
incorrect.
> If this doesn't work I'm will try another route which I cannot write
> about on a public list.
>
> If Mozilla could consider giving me some support, I would be more than
> happy to build on Firefox!
>
on parental leave right now, so this is truly a sideline.) I'm not sure
what else you'd need, other than patience and ingenuity.
> The Web2Native Bridge is the core of a more ambitious effort which among
> many things is about transcending on-line payments from the pitiful state
> it has been in the last 20 years or so. Well, Google and Apple have
> already done that, but I'm targeting the other 99.99999% who don't have a
> platform they can update whenever there's a need.
>
Nick
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
Anders Rundgren
Dec 1, 2016, 5:35:50 PM12/1/16
to
On Thursday, December 1, 2016 at 9:51:36 PM UTC+1, Nicholas Alexander wrote:
<snip>
Hi Nicholas,
I want to avoid a long (and for other people boring) debate, but I feel that I must at least *try* to describe what this is all about...
I would recommend a peek in this document which describes the rationale
https://cyberphone.github.io/doc/web/web2native-bridge.pdf
> The security model of Apps is very poorly understood
> by users and I claim there is no "informed consent".
Right or wrong, this is (IMO) a problem for the OS vendors deal with
and as far as I can see in Android it is evolving.
> I would like the many, many people who have thought about this problem
> involved before we punch a bi-directional hole between these two models.
I have two comments to this:
1. I have tried (really, really hard) to make this happen but it didn't.
2.The Android and iOS URL schemes including Apps that "talk back" through HTTP are already firmly established in the market. My proposal is only about making the concept more usable. BTW, talking back via HTTP is worse security-wise than via the "bridge" since App-based HTTP doesn't obey the browser HTTP security model.
Application using URL scheme and talking back via HTTP:
https://play.google.com/store/apps/details?id=org.webpki.mobile.android
https://test.webpki.org/webpay-merchant/home
> After all, isn't the Canonical Use Case to provide login credentials
> between Web and App so you get a seamless experience with a single
> sign-on? That requires some level of trust between the two models.
I'm not sure I understand what you suggesting here.
The App is vetted by an "AppStore" for "Doing the right thing(tm)" when called from the Web by a browser recognized by the OS as "genuine". There are use-cases where a service may need to authenticate to the App but that is just an option. What's missing is a better filter mechanism than BROWSABLE but that won't happen until the rest is running :-)
I don't know why you say that the JS API is very Android specific. That's certainly not the intent at least. The Application ID is "java-inspired" but if an URL would be better I could change it.
Best regards,
Anders
<snip>
Hi Nicholas,
I want to avoid a long (and for other people boring) debate, but I feel that I must at least *try* to describe what this is all about...
I would recommend a peek in this document which describes the rationale
https://cyberphone.github.io/doc/web/web2native-bridge.pdf
> The security model of Apps is very poorly understood
> by users and I claim there is no "informed consent".
and as far as I can see in Android it is evolving.
> I would like the many, many people who have thought about this problem
> involved before we punch a bi-directional hole between these two models.
1. I have tried (really, really hard) to make this happen but it didn't.
2.The Android and iOS URL schemes including Apps that "talk back" through HTTP are already firmly established in the market. My proposal is only about making the concept more usable. BTW, talking back via HTTP is worse security-wise than via the "bridge" since App-based HTTP doesn't obey the browser HTTP security model.
Application using URL scheme and talking back via HTTP:
https://play.google.com/store/apps/details?id=org.webpki.mobile.android
https://test.webpki.org/webpay-merchant/home
> After all, isn't the Canonical Use Case to provide login credentials
> between Web and App so you get a seamless experience with a single
> sign-on? That requires some level of trust between the two models.
The App is vetted by an "AppStore" for "Doing the right thing(tm)" when called from the Web by a browser recognized by the OS as "genuine". There are use-cases where a service may need to authenticate to the App but that is just an option. What's missing is a better filter mechanism than BROWSABLE but that won't happen until the rest is running :-)
I don't know why you say that the JS API is very Android specific. That's certainly not the intent at least. The Application ID is "java-inspired" but if an URL would be better I could change it.
Best regards,
Anders
Anders Rundgren
Dec 10, 2016, 2:36:50 AM12/10/16
to
The Web2Native Bridge emulator now runs flawlessly on the "desktop" version of Firefox!
I'm still awaiting publishing by Mozilla AddOn team.
You may install temporary right now though:
https://github.com/cyberphone/web2native-bridge/tree/master/firefox/extension
Installation of the host app:
https://github.com/cyberphone/web2native-bridge/tree/master/firefox/install
I'm still awaiting publishing by Mozilla AddOn team.
You may install temporary right now though:
https://github.com/cyberphone/web2native-bridge/tree/master/firefox/extension
Installation of the host app:
https://github.com/cyberphone/web2native-bridge/tree/master/firefox/install
0 new messages