- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Thu, 27 Nov 2014 18:08:15 +0100
- 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