Re: capability restrictions in the runtime strawman

On Mon, Jun 25, 2012 at 10:23 AM, Carr, Wayne <wayne.carr@intel.com> wrote:
>>For instance, the ability to load remote scripts into a secure context creates
>>interesting security issues. Should it be disabled, or should developers who rely on
>>that for trusted apps just be made to dress up as Barney the Dinosaur for the
>>following three months? If remote scripts are verboten, should the same be done
>>to images?
>
> It would seem odd that standalone apps that are the html5 equivalent of "native" apps wouldn't even be able to do the equivalent of what a Web page can do.  There can be the same kind of policy as CSP to set where resources can come from, set at install time.

One specific example that might be worth discussing is whether system
applications can use synchronous XMLHttpRequest.

Synchronous XMLHttpRequest is a bad user experience because it blocks
the main UI thread of the application.  The user experience is
especially bad if there is network latency (e.g., on mobile networks).
 Our experience is that if synchronous XMLHttpRequest is available,
developers will use it because it is convenient and thus will create
poor user experiences.  By contrast, if synchronous XMLHttpRequest is
not available, these same developers will use asynchronous
XMLHttpRequest and create better user experiences.  For that reason,
end users get a better experience if we disable synchronous
XMLHttpRequest in system applications.

Adam


>>-----Original Message-----
>>From: Robin Berjon [mailto:robin@berjon.com]
>>Sent: Thursday, June 21, 2012 5:38 AM
>>To: Carr, Wayne
>>Cc: W3C SysApps
>>Subject: Re: capability restrictions in the runtime strawman
>>
>>Hi Wayne,
>>
>>On Jun 21, 2012, at 00:19 , Carr, Wayne wrote:
>>> The disabled features in the runtime model strawman:  "The runtime must
>>prevent the application from loading remote subresources using mechanisms that
>>do not have a reasonable offline user experience or programmatic error handling.
>>For example, the runtime must prevent the application from loading remote
>>scripts, workers, iframes, images, and style sheets"  Also disallowed: "form
>>submission"
>>>
>>> I understand that's just a straw man, but it may reflect on expectations on what
>>the scope of the WG is.  Our expectation is that these standalone apps can do
>>what browser based web apps can do and more, not less (other than things like
>>history that are dropped because it isn't in a browser).  We'd expect a newspaper
>>app could fetch updated pages, css, images, script and use web workers and
>>submit forms.
>>
>>I don't think that it sets expectations on the WG — so don't worry about that
>>part. What it does do however is make a number of rather bold proposals, and
>>gives everyone time to think about them before the WG kicks in in earnest. You
>>certainly don't have to agree with the choices made by Adam and Erik's
>>document, but I cannot recommend strongly enough that people take the time to
>>acquaint themselves with the questions those choices address.
>>
>>For instance, the ability to load remote scripts into a secure context creates
>>interesting security issues. Should it be disabled, or should developers who rely on
>>that for trusted apps just be made to dress up as Barney the Dinosaur for the
>>following three months? If remote scripts are verboten, should the same be done
>>to images?
>>
>>A lot of the details in the strawman also assume a single-page application. There
>>are good reasons to favour this (I personally do), but I have little doubt that it
>>may be controversial.
>>
>>One interesting question is the ability to take existing Web applications and
>>systemise them. Removing Location might make sense for some aspects (Widgets
>>had the same problem, solved it differently), but it might also kill the routing code
>>that I currently use.
>>
>>--
>>Robin Berjon - http://berjon.com/ - @robinberjon
>

Received on Monday, 25 June 2012 17:46:28 UTC