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

RE: Rethinking "SysApps"

From: Nilsson, Claes1 <Claes1.Nilsson@sonymobile.com>
Date: Wed, 26 Nov 2014 12:16:24 +0100
To: 'Anders Rundgren' <anders.rundgren.net@gmail.com>, "'public-sysapps@w3.org'" <public-sysapps@w3.org>
Message-ID: <6DFA1B20D858A14488A66D6EEDF26AA3031775AD1BBA@seldmbx03.corpusers.net>
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?


Claes Nilsson
Master Engineer - Web Research
Advanced Application Lab, Technology

Sony Mobile Communications
Tel: +46 70 55 66 878


> -----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

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