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 Anders, > > On Tue, Nov 29, 2016 at 9:10 AM, Anders Rundgren < > anders.rundgren....@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 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
