On Wed, Nov 30, 2016 at 2:40 AM, Anders Rundgren <
anders.rundgren....@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
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.

For Web -> App, there is one piece (at least) that prevents the user being
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.

I agree that this would be best at the OS level -- Apple's App Store
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 :-(

Having thought about this during my email, I guarantee you it is
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.

More like starting points, but it will point you in the right direction.

>   I'm also looking into Web Payment API which I (believe) does quite
> similar things albeit in a very specific manner.

I doubt you would find Firefox's (or Chrome's) Web Payments API
implementation instructive at this time, but more power to you if I am

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

I can commit to answering some questions, but little more.  (In fact, I'm
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.

My best wishes,

> 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
dev-platform mailing list

Reply via email to