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

On 10/01/13 07:56, Jungkee Song wrote:
>> 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

Thanks for your swift response!

I wasn't aware of those examples, thanks for the pointers.So in this 
situation the page has no manifest?  Otherwise that would be the logical 
place to put an update URI.

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

Ok, thanks for clarifying.  I agree that there isn't a huge different in 
the runtime model.  The distinction between browsing contexts looks like 
a good way of handling this.

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

Sure.  We've been assuming that system applications would always be 
served over https.  Without that assumption, as you say, it becomes a 
much more complicated issue.  On that note - do people forsee "system 
applications" being served over http?

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

There's an argument that the service end *ought* to be involved in any 
access control decisions around incoming requests from other origins or 
apps. But it depends whether "system applications" really are native 
equivalents (in which case cross-origin requests are always allowed) or 
"privileged websites" (in which case cross-origin requests are special 
exceptions to the same origin rule).

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

A concrete set of threats around cross-origin communication would aid 
this discussion no end.  I wonder if the authors of the Widget 
specifications (WARP in particular) would be able to offer any 
suggestions, as they must have had the same discussion.  When 
applications are isolated in the way you describe, coming up with 
plausible threats that the same origin policy protects against is more 
difficult.

Best wishes,

John

Received on Thursday, 10 January 2013 16:52:11 UTC