[whatwg] Content Restrictions

[Hallvord Reiar Michaelsen Steen]

On 12 Feb 2006 at 0:43, Alexey Feldgendler wrote:

> > 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.

Great that you keep investigating that :-)

> > 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.

Now, I've been asking around and I've been allowed to forward some E-
mails to the list. Here is the initial response from a core DOM 
support developer:

<q>
What is or what isn't technically simple to implement in existing
implementations should perhaps not be what decides how specifications are
written.  It is clear that it is possible to implement per-function
security tracking (though slightly unclear how such security tracking
should work; which of all currently executing functions determine the
security context?)  It is also clear that it hasn't been exactly been
required by implementations yet, so it is likely that an implementation
doesn't have it already.  And since it involves storing more information,
implementing it is likely to cost some in terms of memory use.  And since
it complicates the security mechanisms, it is questionable that it is at
all a good idea.
 
I haven't followed the discussion on the list very closely, but it sounded
to me like a problem best solved some other way.
</q>


[on the proposed HTTP headers for content restriction]

<q>
why doesn't the author simply make
sure to serve the untrusted content from another server (with another
host name or port number, that is, not necessarily another machine)?
Then the current security policies will work fine, and in all current
browsers too, as a bonus.  Or is there a need to share some information
between documents but still have custom restrictions?
</q>

(That might work for webmail but maybe not for blogs?)

> >>> 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?

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

overflow:hidden would solve it, yes (though it means that any bugs in 
overflow:hidden support become potential security issues).

> > 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...

> IFRAME and other such elements (e.g. OBJECT) are very different from  
> SANDBOX because they require loading of external content.

Not with data: uri support in clients :-)
I know what you mean though..

> 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.

An inline inline frame then :-)

My DOM expert comments again, on <SANDBOX>:

<q>
Seems that brings another (although simpler) set of problems though:
what if the untrusted content contains a "</SANDBOX>" tag, or if it
ends with "<!--", or possibly other syntax anomalies?
 
What if it doesn't contain exactly that, but something else that
triggers equivalent behaviour in the HTML parser in some implementation?
HTML parser are traditionally quite complex, and quite "fuzzy".  The
fuzziness hasn't been a security problem before, now all of a sudden it
might be.
 
On the other hand: this would be introduced in a specification that
also specifies how an HTML parser should work.
</q>


Did we discuss how the UA should handle a closing </sandbox> tag? 
Would it need to scan forward in the markup to find other closing 
tags and determine if the current one is a part of the enclosed 
markup or the end of the SANDBOX in that page? Perhaps only the first 
and the last SANDBOX open/close tags can be taken into account and 
others discarded?
-- 
Hallvord Reiar Michaelsen Steen
hallvord at hallvord.com  http://www.hallvord.com/

Assuming that communication is possible is more fun