RE: Rethinking "SysApps"

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?

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 11:16:57 UTC