mjs at apple.com
Wed Nov 25 13:25:30 PST 2009
On Nov 25, 2009, at 12:34 PM, Adam Barth wrote:
> On Wed, Nov 25, 2009 at 12:30 PM, Maciej Stachowiak <mjs at apple.com>
>> 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
>> 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
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.
More information about the webkit-dev