[whatwg] Content Restrictions

On Tue, 31 Jan 2006 10:53:43 +0600, Hallvord Reiar Michaelsen Steen  
<hallvord at hallvord.com> wrote:

>> All code which is physically written inside the sandbox is restricted.
>> This includes setter functions.

> This is very hard to implement. AFAIK no UA's JavaScript engine has a
> concept of the "origin" of a function.

Gecko has... Almost. Actually, it has internal data structures which seem  
suitable for origin tracking. Gecko associates so-called "principals" with  
each compiled function. It just doesn't currently propagate according to  
origin-tracking rules, but it can be done.

> If any function is invoked by a thread with higher privileges,
> it will run with higher privileges. The alternative is having
> the UA do a security check for every function it intends to run,
> and I don't see any way to avoid a serious performance penalty there.

No, why? When a native function is called, like window.open, or  
node.appendChild, it should just look for the principals of the innermost  
caller context (and it's already done, actually, for domain security  
restrictions).

> Caveat: I'm not a programmer, just a tester.

Though I'm a programmer, I've never taken part in browser development. We  
really need an opinion of a browser script engine developer.

>>> Also, how do you prevent inner "safe" script from e.g. overlaying
>>> content on top of any arbitrary part of the page using absolutet
>>> positioning? You have to try and allocate particular bits of the page  
>>> to particular sandboxes. That's a nightmare.

>> Thanks for pointing this issue out, I'll think about how to address it

> Yes, it is a serious problem.

Can't the containing page take care of this with stylesheets? Specifying  
overflow:clip and something like that for the sandbox element.

> Regarding SANDBOX when I look at the discussion and points raised so
> far I sort of get the feeling that we are re-inventing IFRAME...
> Hence I'm beginning to think that we should just come up with a new
> attribute on IFRAME, called "sandbox" or "contentrestriction" or
> something like that. That way the parent page could explicitly allow
> or prevent interaction with the IFRAME.

IFRAME and other such elements (e.g. OBJECT) are very different from  
SANDBOX because they require loading of external content. It would be very  
ineffective for, say, a blog page to load each entry with a separate HTTP  
request. A sandbox is more like an "inline IFRAME", I mean, an IFRAME  
whose content is contained inside the element and not in an external  
resource.


-- 
Opera M2 8.5 on Debian Linux 2.6.12-1-k7
* Origin: X-Man's Station [ICQ: 115226275] <alexey at feldgendler.ru>

Received on Saturday, 11 February 2006 10:43:20 UTC