RE: capability restrictions in the runtime strawman

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

>-----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:24:26 UTC