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

Hi John,

My colleague, Ming, already tried to reply but it seems his email is not
active in the mail list yet. I put (Ming) at the comments he wrote.

> -----Original Message-----
> From: John Lyle [mailto:john.lyle@cs.ox.ac.uk]
> Sent: Wednesday, January 09, 2013 6:59 PM
>
> I found your proposal to be a good read - I think there's some really
> valuable material in here.  A few comments:

Thanks for the review.

> I like the fact that the proposal does not specify a manifest or
> packaging format for now - but does state requirements - that seems to
> allow for all of the existing examples and pass the problem potentially
> over to other specifications.For a stand-alone 'security model' this
> makes a lot of sense.
> 
> I broadly agree with the definition of "system application".  I imagine
> it could still be refined, but probably only after the specifications
> have been settled.


Yes, while merging the proposals, we should refine it for sure. As of now,
it seems we agree on that the "installable" is a major factor making "system
application" different from the normal web application (website). I don't
know the exact history how the name of the WG had been determined but I've
tried to use the term in the proposal.


> 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?


(Ming) 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/R
eference/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.


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


> I really like the definition of three browsing contexts.
>
> 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".


(Ming) 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?


(Ming) 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.


(Ming) 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.


> Issue 5 - relaxing the same origin policy - are there any use cases for
> doing so?  Originally in webinos we were planning to use WARP to specify
> the set of origins that were permitted for a widget.  But CSP seems to
> be more useful.  As such, we decided to stick with the web model (which
> I'm broadly interpreting in this context as "same-origin by default,
> except where permitted by CSP and CORS").  If I understand correctly,
> this is the same in Mounir's proposal.


I believe the needs for cross origin request are already high and the use
cases are getting increased as web applications get more complex. Of course
we have CORS but the deployment seems not very easy and has dependency on
the service end.

That said, I would suggest we discuss whether it's literally impossible to
allow cross domain request based on the trust model that we design in this
WG. At least, we have CSP, separate sandbox for each app (even browsing
context), signature and store audit process, etc.


Best regards,
Jungkee


> I agree with the requirement that a runtime obey a security policy, and
> with the principle of defining a reasonable one in this working group
> (although I suspect it'll need to be a 'recommendation' rather than a
> 'requirement'.  Your point about differentiating between different
> browsing contexts is good.  I do disagree slightly with "Packaged system
> applications are usually verified extensively by an Application Store" -
> I think this gives app stores more credit than is perhaps deserved.
> There are some app stores out there that do little or no verification.
> 
> Best wishes,
> 
> John
> 
>

Received on Thursday, 10 January 2013 07:57:08 UTC