A widget is a small program which lies on top of the main
application. In the case of widgets a transparent iframe looks a good
solution to me. Creating a sandbox will be very, very complex.
Discussions will rise about whether or not the sandbox may render
anywhere on the canvas, or just on a specified area. Though I am not
yet convinced of the advantages I am not totally against.
Intuitively, a sandbox method looks useful to me.
But what to sandbox? If you want to sandbox DOM access, a method
should be available to create multiple DOM's within the same document
with restrictions. Anne, does this conflict with the work of the CDF wg?
<body>
<script type="text/javascript">
window.onload = function () { ... do something ... }
</script>
<div sandbox="true"><!-- any script which is a descendent of this
element cannot see what is outside the DIV element. this becomes the
documentElement.
foo
<script type="text/javascript">
window.onload = function () { ... do something... } // how to
handle this?
</script>
<!-- alerts 'div' -->
<input type="submit" onclick="alert
(document.documentElement.nodeName);">
</div>
<!-- this cannot be reached from inside the sandbox div -->
<div id="outside">
bar
</div>
</body>
This looks inelegant to me.
--jorgen
On Jan 13, 2007, at 1:48 AM, James M Snell wrote:
Comments on a blog, no. (I'm not sure who brought up that use
case). I'm
thinking more along the lines of widgets embedded into a page. E.g.,
many users of our internal blogs like to embed widgets from various
external sites into their templates. Many of these are embedded using
<script src="..." />. Because these scripts run within the context of
the larger page, a potentially malicious script that has access to the
complete DOM could silently scrape content from the page and send that
out to an external server.
Again, I'm not proposing any particular solution. Nor am I saying
there
aren't already existing solutions to these problems that can work.
What
I'm saying is that having some way of isolating a script would be
ideal
and I was curious as to what others had to say about it.
- James
Jorgen Horstink wrote:
On Jan 12, 2007, at 10:30 PM, James M Snell wrote:
Anne van Kesteren wrote:
[snip]
Frames are a terrible solution. The content is after all a part
of the
page it's hosted in, but we want to sandbox it to make sure it
can't
do any harm.
The proposed alternative is severely underdefined and won't work
for the
foreseeable future anyway.
[snip]
Minor nit:
s/proposed alternative/simple strawman to illustrate the point/
I just want the behavior or something that comes close without
necessarily having to resort to aggressive filtering. That is, I
don't
necessarily want to eliminate scripts from the comments, I just
want to
be able to limit their impact.
Either way, I'm fully aware that any new invention here would take a
while to actually work.
- James
Please provide a real use case. I second Anne's point of comment
sanitation. Can you give me one single use case when it is useful
to use
ECMAScript in a comment on a blog? Secondly, just as Bjoern states; a
malicious script could easily position new element on top of other
elements. Or do you want to restrict that too? I cannot see what
CSS has
to do with it, since it is not a style issue, but a DOM access
behavior
issue.
-- Jorgen
