[whatwg] Content Restrictions

[Alexey Feldgendler]

On Mon, 30 Jan 2006 22:42:48 +0600, Gervase Markham <gerv at mozilla.org>  
wrote:

> I picked that particular implementation method for a reason. When I
> proposed various ideas to the Mozilla security group, I was told that an
> idea something like <sandbox> would be extremely difficult to implement,
> whereas Content-Restrictions would fit in well with the capabilities
> system of the browser.
>
> Of course, <sandbox> may be different enough in the details that it's a
> lot easier to implement - I don't know.

It would be very interesting to hear opinions of Mozilla security group on  
this particular proposal about <sandbox>, and maybe some changes would  
turn it from difficult to simple. As I'm not an implementer of a browser,  
I don't know what is simple to implement and what is not.

> If you want to write up <sandbox> in a spec, that's up to you. But a
> quick skim-read of your list of seven points leads me to think that the
> devil is in the detail. For example, how do you programmatically isolate
> the outside and inside? If the outside sets a value on the inside, and
> the inside has set a setter function on that value, how do you make sure
> the setter runs with the right privileges?

All code which is physically written inside the sandbox is restricted.  
This includes setter functions. It doesn't matter how did the function get  
called -- as a result of an event, or because it's called from the  
outside, or because it's a setter.

> These are all issues Firefox has faced when trying to sandbox content
> inside chrome, and it required a large change to the way the two
> interacted (XPCNativeWrappers, if you want to Google for it). I guess
> it's possible that this mechanism could be reused to sandbox content
> from other content...

Yes, I'll learn about XPCNativeWrappers and maybe correct my proposal so  
that it's closer to what is actually implemented.

> 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, if  
it needs to be addressed at all. Maybe a set of restrictions should be  
specified as attributes of the <sandbox> element, similar to your  
restrictions like "create".

>> http://www.livejournal.com/support/faqbrowse.bml?faqid=14
>> They clearly state that they would like to allow scripts, but they don't
>> know how to do it safely. I think it's not just a problem of this  
>> particular site.

> I know people _want_ to do it, just as people wanted pretty coloured
> scrollbars and so IE added a proprietary extension to CSS to allow it.
> What I don't see is a compelling reason _why_ - something above the
> "Ooh! Coloured scrollbars!" level.

Scripts today is not just like coloured scrollbars. Maybe scripts aren't  
particularly useful within blog entries, but there is a place where they  
can be useful: in user-defined journal styles. AJAX can be used to create  
a highly interactive style (rich user experience). Currently, JS in  
user-defined journal styles is forbidden, too, because of the cookies.


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