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

Thanks for your reply Marcos. I see your point on digital signing and packaging and understand the difficulties in standardizing this. So am I right in thinking that we, if we don't standardize digital signature schemes and packaging, will have something that is a bit similar to the Phonegap/Cordova concept? That is, developers will be able to use a set of standardized APIs and write apps with html, css, js and a manifest that are basically portable between different runtimes platforms that complies to the SysApps specifications. However, each device runtime supporting SysApps must have an associated tool chain that signs and packs the application according to the specifics of this runtime.

IS this what we want to achieve? 

BR
  Claes

> -----Original Message-----
> From: Marcos Caceres [mailto:w3c@marcosc.com]
> Sent: den 25 september 2013 12:48
> To: Nilsson, Claes1
> Cc: Kenneth Rohde Christiansen; Dave Raggett; public-sysapps@w3.org;
> Isberg, Anders
> Subject: 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 Friday, 27 September 2013 13:23:03 UTC