W3C home > Mailing lists > Public > public-sysapps@w3.org > November 2014

Re: Rethinking "SysApps"

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Thu, 27 Nov 2014 18:08:15 +0100
Message-ID: <54775A7F.6010608@gmail.com>
To: "Kis, Zoltan" <zoltan.kis@intel.com>
CC: "Nilsson, Claes1" <Claes1.Nilsson@sonymobile.com>, "public-sysapps@w3.org" <public-sysapps@w3.org>
On 2014-11-26 14:06, Kis, Zoltan wrote:
> Hi Anders,
Hi Zoltan,
I will try to answer you comments as well as I can:-)

>
> In the use case of calling a number, indeed it resembles an
> intent-like API, which launches from a remote site a local dialer,
> trusted (non-fakeable) and controllable by the user. It is not
> possible to hide that from the web page embedding the "intent" in
> order to make latent calls to expensive numbers, nor to get any
> private data over to the calling context.

That's the intention.

>
> This is a nice use case, but this mechanism seems wider to me than
> just sysapps. We should indeed rather talk about trusted vs not
> trusted apps, instead of sysapps or web apps.

That's true but there is a snag: How can a user separate a trusted
app from a non-trusted ditto?  Due to this I have so far at least
only considered this scheme for bringing out "dangerous" APIs to
the web in order to make the web more competitive and useful.


> Then, IIUR, this mechanism is orthogonal to the Telephony API itself
> (in this use case), just that the platform needs to be able to support
> it, and implementations need to validate the number. Or do you see
> that are there implications on the API?

I hope not but it is imaginable that some APIs need tweaking to be useful in
this scenario.  The trusted apps in turn have their own postMessage()-based
APIs which are application-specific like in the payment demo.


> If similar use cases (e.g. SMS, email, etc) are limited to "send"
> functionality with a validable input, this may work.
> Besides "send" type of functionality, would there be use case for
> handling events?

Essentially any functionality that 1) could be useful 2) would not jeopardize
the user's privacy or the platform's integrity could be applicable. I don't have
any deeper insight in the various SysApp APIs so I leave this to the experts :-)

My own interests is primarily getting the run-time model in place which is non-trivial.
I may be able coming up with some kind of straw-man next week.

Best regards
AndersR

>
> Best regards,
> Zoltan
>
> On Wed, Nov 26, 2014 at 2:38 PM, Anders Rundgren
> <anders.rundgren.net@gmail.com> wrote:
>> On 2014-11-26 12:16, Nilsson, Claes1 wrote:
>>>
>>> Hi Anders,
>>>
>>> These are interesting thoughts and the payment demo makes sense. However,
>>> I am not sure on this as a general solution for access to sensitive APIs. In
>>> your example with the phone call utility on a customer support web-page I
>>> assume that you mean that the telephone API is accessed by the IFRAME code,
>>> which is a trusted hosted SysApps. However, the surrounding untrusted app
>>> still has to instruct the trusted app, through postMessage, on the phone
>>> number to call. So we still have a security issue and I assume that we will
>>> have similar issues for other APIs. Or have I misunderstood your concept?
>>
>> Thanx Claes for looking into this, I really appreciate it!
>>
>> Your understanding of the concept is correct.  That means that an embeddable
>> SysApp MUST shield sensitive APIs and Users from various misfortunes.  For
>> the phone application the untrusted code can only supply the phone-number,
>> while the actual "Call" button must be a part of the embedded SysApp's
>> "Trusted UI".
>>
>> Payment applications are more complex since they could potentially leak
>> identity-related information.  Hopefully the payment demo is not too far
>> from what a real payment application would do.
>>
>> There may indeed be SysApps that does not fit this model but then they
>> probably have no use of the web either.
>>
>> Best regards,
>> Anders R
>>
>>
>>>
>>> BR
>>>     Claes
>>>
>>>
>>> Claes Nilsson
>>> Master Engineer - Web Research
>>> Advanced Application Lab, Technology
>>>
>>> Sony Mobile Communications
>>> Tel: +46 70 55 66 878
>>> claes1.nilsson@sonymobile.com
>>>
>>> sonymobile.com
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Anders Rundgren [mailto:anders.rundgren.net@gmail.com]
>>>> Sent: den 26 november 2014 09:48
>>>> To: sysapps
>>>> Subject: Rethinking "SysApps"
>>>>
>>>> Dear List,
>>>>
>>>> Since the SysApps runtime model still seems to be incomplete or
>>>> missing (?), I take the liberty outlining another model which has
>>>> grown out of my work with Payments, Identity and Security Tokens.
>>>>
>>>> There's obviously a need for locally installed systems applications
>>>> like telephone dialers but these are IMO just like other "Apps" and I
>>>> have nothing to add here.
>>>>
>>>> So quickly over to something completely different...
>>>>
>>>> Let's say that you wanted to have a phone call utility on a customer
>>>> support web-page.
>>>> This is already available but through proprietary solutions, right?
>>>>
>>>> This could be done in a portable fashion through a hosted SysApp
>>>> created as an IFRAME and then embedded by the customer support web-page.
>>>> That is, the UA would still consider the code as trusted but it would
>>>> also be able to communicate through postMessage() which is much nicer
>>>> than web-intents (which BTW appears to have died somewhere down the
>>>> road...).
>>>>
>>>> For payments this would be even more useful since a local wallet like
>>>> Apple Pay doesn't really work on the web.  A hosted, transiently
>>>> downloaded wallet would security-wise be identical to the same wallet
>>>> application locally installed, while still being embedded by a
>>>> untrusted merchant application.
>>>>
>>>> The upper part of the WebCrypto++ specification illustrated on
>>>> http://webpki.org/papers/PKI/pki-webcrypto.pdf#page=2
>>>> shows how the hosting, packaging and application isolation would be
>>>> architected.
>>>>
>>>> However, unlike WebCrypto++, the signature must now be trusted by the
>>>> *platform*.
>>>>
>>>> If this is actually working, it could give the web a well-deserved
>>>> push forward; right now the battle between native and web appears to
>>>> be rather uneven.
>>>>
>>>> Even if you are not interested in payments, you may using a recent
>>>> Chrome (or Firefox/Beta), try the following semi-mockup/demo which hi-
>>>> lites the potential of hosted, embedded and locally trusted apps that
>>>> also aren't being crippled by SOP:
>>>> https://mobilepki.org/WebCryptoPlusPlus
>>>>
>>>> Thoughts?
>>>>
>>>> Cheers,
>>>> Anders R
>>>>
>>>>
>>
>>
Received on Thursday, 27 November 2014 17:08:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:36:21 UTC