RE: capability restrictions in the runtime strawman

My concern was with what gets in the charter, not to overly restrict what options the WG has.  The charter turned out fine.

>-----Original Message-----
>From: Robin Berjon [mailto:robin@berjon.com]
>Sent: Tuesday, August 07, 2012 5:02 AM
>To: Carr, Wayne
>Cc: W3C SysApps
>Subject: Re: capability restrictions in the runtime strawman
>
>Hi Wayne,
>
>I've been meaning to come back to this for while, but for some reason I forgot.
>
>On Jul 9, 2012, at 17:04 , Carr, Wayne wrote:
>> I think to satisfy everyone we may need more than one security model.
>
>I would sincerely hope not. Down that path lies a general purpose, configurable
>policy model. For a developer, not being allowed to use a feature or the feature
>not being implemented are the same thing. There can be some variations in how
>some sensitive features get enabled (automatically, by user permission, etc.) but
>if you start having some fundamentals behave differently in different places then
>you might as well not have a standard at all because for all intents and purposes
>you have no useful interoperability.
>
>> One use for these specs is to create systems where Web technologies are the
>only type of application, or is a primary type of application.  There may be no
>native applications.  For this class there cannot be restrictions like not being able
>to display an image that is retrieved from the web.
>
>I would wait for the detailed discussion to take place before making such
>sweeping statements :)
>
>One problem you may have if you're running an app store or some form of
>service that checks apps is their ability to load remote code. An app might look
>entirely innocuous but then maliciously load code stored remotely. Or it might
>actually be innocuous but get some malicious code injected into it. These things
>are dangerous enough in a browser context, they're lethal in a system context.
>That's one consideration that can lead to restrictions (perhaps drastic e.g. no
>remote scripts, no eval() or new Function(), no script-generated script elements
>with content, no script data URLs, no on* attributes, and the list just goes on).
>
>Another consideration is user experience. The problem with something like <img>
>is that you have limited control over error handling (unless you have a manifest
>that can specify fallbacks, which is an interesting alternative — I don't think the
>error event ever works in real browsers, does it?). If you want to display remote
>images, you might therefore be better off loading them with XHR so that you can
>detect problems.
>
>And other considerations can come into play. I'm not saying that they necessarily
>override your concerns, which I well understand. But in a few weeks' time this
>group will get started (or so it seems likely). We're going to have to take a deep
>breath and probably challenge some of the assumptions we have about Web
>development. Not too many of them though, or we'll lose developers and
>libraries. But it's going to be complicated to sort out properly because we're
>getting as close as it can possibly get to starting from scratch and the implications
>of the security model are so pervasive in the Web platform that there will be
>obscure and twisted little passages galore.
>
>So I'd like to invite all of us, and I'm definitely not pointing a finger at Wayne at all
>here, to avoid both overly sweeping statements before we've looked at the
>problems (particularly security and global UX ones) and to only give in to
>variability in the model where it is either harmless or strictly necessary.
>
>--
>Robin Berjon - http://berjon.com/ - @robinberjon
>

Received on Friday, 17 August 2012 18:29:38 UTC