[webkit-dev] Best way to disable JavaScript

[Jochen Eisinger]

On Mon, Mar 18, 2013 at 7:27 AM, Arunprasad Rajkumar <ararunprasad at gmail.com
> wrote:

>
>
> On 18 March 2013 13:00, Jochen Eisinger <jochen at chromium.org> wrote:
>
>>
>>
>>
>> On Sun, Mar 17, 2013 at 8:26 PM, Geoffrey Garen <ggaren at apple.com> wrote:
>>
>>> Hi folks.
>>>
>>> Currently, we have two different ways to disable JavaScript execution:
>>>
>>> (1) Paste / Drag n Drop / editing: Remove script elements and script
>>> attributes from untrusted source markup at parse time.
>>>
>>> (2) JavaScript disabled setting / Content Security Policy: Check
>>> settings and/or CSP at runtime.
>>>
>>> There are problems with mode (2):
>>>
>>> * It breaks features that are implemented in JavaScript.
>>>
>>> The Web Inspector, bookmarklets, extensions, Safari Reader, and Safari
>>> autofill all run JavaScript. This means that they break when users disable
>>> JavaScript.
>>>
>>
>> I'm not sure I understand:
>>
>> We only invoke canExecuteScript for scripts in the main world, so running
>> extensions (or anything else that's running in an isolated world) should
>> not be affected.
>>
>
> Inspector injected scripts will be in main-world right? Sorry in-case I'm
> wrong :)
>


AFAIK they're in an isolated world (of course unless you type some
javascript into the console, that would be executed in the main world and
then be blocked)

If the inspector scripts were injected into the main world, the page could
mess with them

And the inpsector frontend is also running its scripts in the main world,
but that is easy to whitelist.

-jochen


>
>>  Also, the actual permission check is done via
>> FrameLoaderClient::allowScript and ::allowScriptFromSource, so blocking
>> e.g. only scripts from the web, but not from the inspector should also be
>> possible.
>>
>> best
>> -jochen
>>
>>
>>> As a defense against phishing attacks, mail clients and other web
>>> content readers disable JavaScript. This means that they can't implement
>>> pieces of their UI in JavaScript.
>>>
>>> (FWIW, WebKit violates the CSP specification in this regard: "Enforcing
>>> a CSP policy should not interfere with the operation of user-supplied
>>> scripts such as third-party user-agent add-ons and JavaScript
>>> bookmarklets.")
>>>
>>> * It subjects users to XSS attacks.
>>>
>>> Runtime checking mode leaves inert JavaScript in the untrusted document.
>>> This is a risky proposition. Operations that clone or adopt nodes from the
>>> untrusted document unwittingly re-vivify that inert JavaScript, subjecting
>>> the user to attack. Experience shows that this is a difficult programming
>>> model to get right.
>>>
>>> * It's hard to verify.
>>>
>>> We have 18 different call sites to canExecuteScripts() in WebKit, not
>>> counting the call sites that pertain to plug-ins. Are you confident we've
>>> caught all the right places? Do you know if the feature you just added
>>> needs to call canExecuteScripts()?
>>>
>>> * It's two different ways to do the same thing.
>>>
>>> Simplicity is a goal of the WebKit project.
>>>
>>>
>>> Proposal:
>>>
>>> If -- for any reason -- JavaScript is disabled in a given document, the
>>> document parser will elide all JavaScript. This means that runtime checks
>>> can be removed.
>>>
>>> One potential downside to this proposal is that it changes the
>>> document's internal structure. Since the changes are not generally
>>> observable, since they only take place when we're already making much
>>> bigger changes by preventing whole scripts from running, and since we
>>> haven't seen any compatibility problems from our paste / drag n drop /
>>> editing behavior in this regard, I think this downside is acceptable.
>>>
>>> Another potential downside is that CSP errors will be reported at parse
>>> time instead of runtime. FWIW, some authors might see this as an upside.
>>>
>>> Any objections?
>>>
>>> Thanks,
>>> Geoff
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>
>>
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>
>
>
> --
> *Arunprasad Rajkumar*
> http://in.linkedin.com/in/ararunprasad
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130318/105dc4a4/attachment.html>