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

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 provide 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. But if the group thinks that the separation of “packaged” and
“hosted” types is necessary for the sake of spec clarifications, we
probably can adopt the terms.


> 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 in my opinion, this is
non-trivial issue and we need to consider both sides of the world.

Regards,
Ming Jin