[webkit-dev] innerStaticHTML

[Maciej Stachowiak]

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