[webkit-dev] Best way to disable JavaScript

[Adam Barth]

On Tue, Mar 19, 2013 at 1:21 AM, Maciej Stachowiak <mjs at apple.com> wrote:

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

You wrote that the behavior would change.  I wrote that the change in
behavior would violate the Content-Security-Policy specification.  I think
we can both agree that violating security specifications creates security
risks.


> Both of these, plus the plugin issue, would in principle be addressable by
> both stripping and blocking at runtime, but not by stripping alone.
>

That would also violate the Content-Security-Policy specification.

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

WebKit::WebPermissionClient::allowScript is called just before WebKit
executes script.  The return value lets the embedder override the default
setting about whether to allow this particular script execution.

WebKit::WebPermissionClient::didNotAllowScript is called just after WebKit
blocks a script from executing.  This notification is sent if, and only if,
the script in question was about to execute.  This API is the reason why we
distinguish the ReasonForCallingCanExecuteScripts between
AboutToExecuteScript and NotAboutToExecuteScript.

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

As far as I can tell, this change is a non-starter.  If I don't reply to
this thread further, please don't mistake my lack of engagement for
agreement.

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