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

Hi John,

On Jan 11, 2013, at 1:51 AM, John Lyle <john.lyle@cs.ox.ac.uk> wrote:

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

Mobile Safari's solution does not have manifest defined for the page, while Chrome's CRX-less solution has manifest (but "update_url" and "version" fields are not part of the manifest for unknown reason). Manifest-based solution is more expressive, has advantage of reusing the standard manifest format that this WG will define, and can provide a way to implement update mechanism as well.

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

I think we should consider pages delivered with "http" in a "system application", otherwise it will create a non-trivial burden for web app developers. By the time of FPWD for "execution/security model", I believe we can clearly define the boundary of a "system application".

Thanks,
Ming Jin

Received on Saturday, 12 January 2013 16:09:00 UTC