[webkit-dev] Best way to disable JavaScript

[Maciej Stachowiak]

On Mar 19, 2013, at 1:05 AM, Adam Barth <abarth at webkit.org> wrote:

> On Tue, Mar 19, 2013 at 12:48 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>> From other discussion on the list, it seems there are two possible ways to
>> disable JavaScript execution without breaking client, user or extension
>> scripts:
>> 
>> (1) "Parser Strip" - strip scripting constructs such as <script> tags, event
>> listener attributes, and javascript: URLs at parse time.
>> (2) "Block Main World" - disable scripting at runtime, but only for the main
>> world, and ensure that all non-page script runs in a separate isolated
>> world.
>> 
>> The message below discusses some possible implementation mistake risks of
>> one approach, but I thought it might be useful to enumerate the observable
>> differences in behavior between the two approaches, assuming for the time
>> being they are implemented perfectly. Here is a list, without at this time
>> judging which behavior is better or worse:
>> 
>> (These all assume we're in the "scripting disabled" state)
>> 
>> Parser Strip                            | Block Main World
>> ----------------------------------------|-------------------------------------------
>> Scripting constructs don't show up in   | Scripting constructs show up
>> normally in
>> Web Inspector                           | Web Inspector
>> ----------------------------------------|-------------------------------------------
>> Extensions can cause script to run in   | Extensions cannot run script in
>> the main
>> the main world via <script>, onfoo, or  | world.
>> href="javascript:"                      |
>> ----------------------------------------|-------------------------------------------
>> When plugins are enabled but javascript | When plugins are enabled but
>> javascript is
>> is not, plugins can execute script      | not, plugins cannot execute script
>> ----------------------------------------|-------------------------------------------
>> When scripting is disabled only for some| When scripting is disabled only
>> for some
>> frames, manipulating the DOM of a frame | frames, manipulating the DOM of a
>> frame
>> with script disabled may cause script to| with script disabled will not
>> cause script
>> run there.                              | to run there.
>> ----------------------------------------|-----------------------------------------------
>> Copying markup from a script-disabled   | Copying markup from a
>> script-disabled
>> frame into a script-enabled context     | frame into a script-enabled
>> context may
>> cannot cause script to run.             | cause script to run (unless the
>> code doing
>>                                        | the copying strips scripting
>> constructs).
>> ----------------------------------------|-----------------------------------------------
>> Ditto above for adopting nodes.         | Ditto above for adopting nodes.
>> ----------------------------------------|-----------------------------------------------
>> 
>> That's all I can think of offhand. Are there any other observable behavior
>> differences?
> 
> As I wrote in my original reply, it's not possible to implement
> Content-Security-Policy correctly without blocking scripts from
> executing at runtime.

I believe this is covered by my "when scripting is disabled only for some frames", but I guess I should have mentioned that this specifically includes the current behavior of CSP.

Both of these, plus the plugin issue, would in principle be addressable by both stripping and blocking at runtime, but not by stripping alone.
 
> 
> Another observable consequence is that moving to a parser-stripping
> implementation would break a number of Chromium WebKit APIs including,
> but not limited to, the following:
> 
> 1) WebKit::WebPermissionClient::allowScript
> 2) WebKit::WebPermissionClient::didNotAllowScript

For benefit of those of us unfamiliar with these APIs, could you please clarify what they do and why they are incompatible with a parser-stripping implementation?

> 
> In case it's not clear from this message (and my previous messages), I
> object to this change.


Thanks for being explicit.

Regards,
Maciej

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130319/aeaecd2b/attachment.html>