On Thursday, December 1, 2016 at 9:51:36 PM UTC+1, Nicholas Alexander wrote:
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
> 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
Application using URL scheme and talking back via HTTP:
> 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.
dev-platform mailing list