W3C home > Mailing lists > Public > public-sysapps@w3.org > August 2012

RE: capability restrictions in the runtime strawman

From: Carr, Wayne <wayne.carr@intel.com>
Date: Fri, 17 Aug 2012 18:28:39 +0000
To: Robin Berjon <robin@berjon.com>
CC: W3C SysApps <public-sysapps@w3.org>
Message-ID: <52F8A45B68FD784E8E4FEE4DA9C6E52A3FC1DC95@ORSMSX101.amr.corp.intel.com>
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

This archive was generated by hypermail 2.4.0 : Thursday, 1 July 2021 16:04:39 UTC