Re: Rethinking "SysApps"

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 12:38:45 UTC