[whatwg] Content Restrictions
Alexey Feldgendler
alexey at feldgendler.ru
Sat Feb 11 10:43:20 PST 2006
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>
More information about the whatwg
mailing list