Privileged and certified-level app, was Re: Clarity over direction of work on runtime and security model?

Breaking this up into multiple threads… will address the questions over time.  


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

> This makes me a bit puzzled.
>  
> * Don't we for example need to specify somewhere what a privileged and certified-level app is? Will that be part of the manifest specification?
Sure, we can. But the runtime spec does not define how one gains such certification (i.e., it is silent on digital signatures in particular). So this would only be paying lip-service to the idea but with some consequences:

If everyone is already using a different digital signature scheme for packaged apps (and I know Mozilla is, and Google is, and I'm sure Tizen is), and has infrastructure in place already for that, it seems like a huge ask to change that infrastructure to support something new. From experience with various other packaged apps endeavors, even selecting a signing scheme and implementing it correctly is a hugely complicated/expensive/political undertaking with a thousand pit falls along the way (tooling, CA management, formats, canonicalization, etc. - anyone that was involved with W3C Widgets knows this sad story).

This means that, from the get-go, certified and privileged packaged apps cannot be shared across runtimes in an interoperable manner (without replacing the signature, which kinda defeats the purpose).

Question for the SysApps WG is: do we want to attempt to standardise a digital signature scheme for packaged apps?  

> Will that be part of the manifest specification?
I don't think it should be, because the type of application is orthogonal. The manifest should only define things needed to bootstrap the application and to support UI (e.g., the start file and CSP tightening maybe.) - app store specific things should be handled at the store. The access rights to APIs is determined by which digital signature a package contains - and that can be determined when it's signed by the signer (i.e., the store and browser vendor).  

To put this into a manifest would merely hint to a store that it wants to be signed in some particular way (or *may* be useful during development, as it can serve as a hint when an app is side-loaded - something that could easily be handled by a UI in a developer tool: "run this as… normal | privileged | certified") - but it doesn't play any other role in the lifecycle of the application because its certification level still depends on the APIs it wants to access and having a digital signature (hence, it's not needed IMHO).

> * I don't think that the user should be able to configure whether prompting should occur or not.
How prompting is done or who controls the prompts is outside the scope of standardization (it's a UX concern). All we can do is make weak recommendations there (like Geolocation does, for instance). It is often the case that certified apps don't prompt at all (i.e., a third party, such as a device manufacturer, operator, or browser vendor, makes that security choice for the user a lot of the time - not always a good thing - not always bad either - just sayin' it happens).  


Kind regards,
Marcos

Received on Wednesday, 25 September 2013 10:48:36 UTC