[webkit-dev] Best way to disable JavaScript

[Arunprasad Rajkumar]

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

>
>  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/3ce7319f/attachment.html>