Achieving interoperability, was Re: Clarity over direction of work on runtime and security model?

On Wednesday, September 18, 2013 at 10:27 AM, Nilsson, Claes1 wrote:

>  
> Generally we are now in situation where it is very unclear on what should be normatively specified and what should stay implementation specific. I think that we should agree on some plan for web system apps runtime and security that includes:
>  
> 1. What will be normatively specified and what should stay implementation specific so that interoperability could be achieved.
>  

If anything, the WG undoubtedly wants some degree of API interoperability. It's already been demonstrated that runtimes can have their own security models and certification-processes, but still make use of a shared pool of Web Platform APIs (e.g., Tizen, Cordoba, Firefox OS all use different security models and rely on different certification infrastructure, but all can potentially use the common W3C's Web Platform APIs. so long as those APIs are supported by the underlying engine). Not having a common security model has not stopped these ecosystems from sprouting up.  

IMO, given the rapid rate at which new APIs are added to proprietary platforms (including Firefox OS here!), it seems fairly unrealistic to think that, for example, a Tizen app will run on Firefox OS (recall also the digital signatures problem I mentioned in my other email!). Although it might be possible, such an app would be quite limited given the differences in proprietary APIs across runtimes. Also, Firefox OS is adding new fields to their manifest on what seems like a weekly basis - this is mostly in response to market pressure and trying to address specific use cases that we haven't even touched on in this group (e.g., packaged apps that can be used as custom keyboards, for instance - I've even heard talk of wallpapers as packaged apps…). I'm sure Tizen will probably face similar challenges, if it hasn't already.  

So, standardizing some of the API surface is a good thing - but, IMO, standardization should only happen for APIs that have maximum benefit for developers (not just a handful who will ever get access to certified-level APIs). Task Scheduler is a good example of "the right thing to do"™ - it is universally applicable and can probably be secured to allow it to be generally available to the Web platform without requiring special permissions.  

The value of SysApps has been to get some agreement of what functionality and services should be available at a platform level (telephony, messaging, raw sockets, etc.). But the security problems around enabling these APIs to a sensible number of developers remains, at least in my mind, something that we need to address. If we can't address the security issues (i.e., we just say "you need a digital signature, and you need to go through our store - deal with it!"), there may still be value in standardizing some of these APIs, but only because the quality of the API is much better than what is currently available in all our platforms. Raw Sockets may be one such API - that although limited in who can access it, it provides an API that's potentially orders of magnitude better than what is implemented in our proprietary platforms.   

Thoughts?

Received on Thursday, 26 September 2013 20:39:16 UTC