Re: [Execution and Security Model] Proposal from Samsung Electronics

It seems that my previous email hasn't reached to public-sysapps. So I am
sending it again.

Hi John,

> I suggest that "the runtime _SHOULD_ support updating of an installed
system application" might be changed to "_MUST_". Do you have any situation
in mind where update wouldn't be supported?

There are three delivery scenarios mentioned in the "Delivery" section of
the proposal. Among the three, “Export from Browser” scenario is something
that may not be easy to have an update mechanism. In this scenario, a
Browser will load a website, and during the parsing of the html header, the
Browser notices that there's an indication in the html header that the
website can be exported and installed on user's home screen as a system
application. There're two kinds of approaches already:
- Mobile Safari's “apple-mobile-web-app-capable” meta tag [1]
- CRX-less web apps in chrome experiment [2]

This scenario provides a handy way to export a “sys-app ready” websites to
user's home screen. But  once installed, there's no easy way for the server
to inform the Browser about any update from the server-side (such as icon
update) unless the user revisits the website in Browser. If we can define a
reliable way to do update for this scenario, we probably can change
_SHOULD_ to _MUST_.

[1]
http://developer.apple.com/library/safari/#documentation/AppleApplications/Reference/SafariHTMLRef/Articles/MetaTags.html
[2] https://developers.google.com/chrome/apps/docs/no_crx

> With regards to uninstallation - presumably the intention is that a
runtime must support it, but doesn't necessarily allow anyone to do it?
 I'm thinking of situations where certain system applications are
pre-installed by the owner of the platform (e.g., a corporation) and
shouldn't be removed by the end user.

Yes you are right. The intention was to describe uninstallation
requirements, but not to specify any security policy here.

> I'm not so keen on the three-tiered untrusted/trusted/privileged.  I
think the tiers are sensible, but it would make more sense to describe them
as (roughly speaking) "unrecognised" / "recognised" /  "privileged".  It's
quite possible that an "untrusted" system application could, in fact, be
trustworthy and also trusted by the end user.  If it has been downloaded
and is static on the file system, it's integrity could be considered safe
anyway, so the fact that it is unsigned has very few security implications.
 The value of signatures is in identifying and categorising applications
for the first time, and for updates.  E.g., in webinos (and the same is
true in Android) we have a policy setting for allowing/denying the
installation of applications without valid certificates.  Once installed,
it's unlikely that any security policy would differentiate between an
"untrusted" and "trusted" application for access control reasons, it is
much more likely to differentiate between "trusted" and "privileged" -
e.g., "only applications from Samsung can access Telephony" is more likely
than "only applications from a known authority can access Telephony".

By “untrusted” I meant “unauthenticated” or “unsigned”, hence the
application's “developer” or “distributor” is “unrecognized” or simply
“untrusted” from the runtime perspective. This is the default assumption by
the runtime. But like you said, if the runtime shows warning of the
potential dangers of installing “unauthenticated” application, and if the
user accepts that warning, the runtime may escalate the application's
privilege from “untrusted” to next level, but I am not sure whether the
next level should be “trusted”, as I think most of the time the user just
blindly accepts the warnings and will not read the potential damages line
by line. So for now I just categorized them as “untrusted”, and I would
happy to discuss about the tiers within this group.

> The CSP conflict issue  (issue 4) is one I've been trying to solve in
webinos, too.  But I'm a little confused - does this mean that a system
application can be hosted online?  I thought (from other parts of your
proposal) that apps were always downloaded and then served from the local
device. Are you saying that - if the application is just one file - it can
be served over HTTP?

Yes, our proposal assumes that a system application can be hosted online as
a whole or partially. In other words, the proposal covers both “packaged”
and “hosted” types of system applications, but we didn't explicitly
differentiated “packaged” type from “hosted” type throughout the document,
as we think that difference is more on developer side as a delivery
mechanism difference but not on runtime side (also slightly mentioned in
“Delivery” section). From runtime perspective, “packaged” or “hosted” is
the matter of whether a browsing context is from “local” or “remote” and
hence whether the browsing context can inherit the application's privilege
or not.

> For the sake of simplicity, there's an argument for ignoring header-based
CSP and requiring it in the manifest. However, in webinos, for hosted
applications my current proposal (and this really is only mine - it hasn't
been reviewed yet) is that applications have a system-imposed default CSP
which can then be modified either by a manifest or by HTTP headers.  The
modifications are only permitted in certain ways - e.g., adding more values
to the connect-src, overwriting media-src and image-src to be _more_
restrictive.

For “hosted” applications, CSP policy in HTTP header may provide
page-by-page policies, while the CSP policy in manifest is application-wide
policy. On the other hand, the problem with CSP in HTTP header is that it's
delivered from remote, so it may have been modified via man-in-the-middle
attack if it's delivered by http:// protocol or the server may have been
hacked even if it's delivered by https://. So the CSP enforcement rule
should consider these facts.

Regards,
Ming Jin