Re: Rethinking "SysApps"

Hi Anders,

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.

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.

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?

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?

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 Wednesday, 26 November 2014 13:06:34 UTC