On Nov 25, 2009, at 12:34 PM, Adam Barth wrote:
On Wed, Nov 25, 2009 at 12:30 PM, Maciej Stachowiak <[email protected]>
wrote:
On Nov 25, 2009, at 6:05 AM, Adam Barth wrote:
Maybe we should have a DOM API called
webkitJailChildren("no-script-for-you") on Node that prevents future
children from running script. Making it a DOM API prevents authors
from trying to turn the feature on with markup.
Interesting idea. This seems potentially trickier to implement than
just
innerStaticHTML, since nearly every method that mutates the DOM
will have to
check jail status. innerStaticHTML could be limited in scope to only
operations that happen as part of parsing.
Instead of checking every DOM mutation, we could just walk the parent
pointers before executing a script to see if an ancestor is jailed.
A few thoughts:
1) Presumably we'd want to block instantiation of plugins and Java
applets too, or the scripting restriction becomes toothless. Perhaps
also iframes, unless the scripting restriction is intended to
propagate across frame boundaries.
2) Capturing all points at which script execution occurs and tracing
them back to the originating element may be tricky. javascript: URIs
are one potentially subtle example. By the time the JavaScript for
those gets executed, I believe we no longer know the originating
element, the way the code is currently structured.
3) It seems like the rule "don't execute JS" might not be quite what
is desired, since it would (presumably) prevent the parent itself from
using event listeners on nodes in the jail. IMO the best treatment for
event listeners would be to prevent them from being created by
attributes, rather than to prevent them from executing.
4) Do we need to strip or rename id, name and class values to prevent
interference with the containing page's use of getElementById() and
such? Caja does.
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
