On 18 March 2013 13:00, Jochen Eisinger <joc...@chromium.org> wrote: > > > > On Sun, Mar 17, 2013 at 8:26 PM, Geoffrey Garen <gga...@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@lists.webkit.org >> https://lists.webkit.org/mailman/listinfo/webkit-dev >> > > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > > -- *Arunprasad Rajkumar* http://in.linkedin.com/in/ararunprasad
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev