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 Tuesday, 7 August 2012 12:02:27 UTC