On Tue, Mar 19, 2013 at 11:42 AM, Maciej Stachowiak <m...@apple.com> wrote:
> > On Mar 19, 2013, at 11:12 AM, Geoffrey Garen <gga...@apple.com> wrote: > > In case it's not clear from this message (and my previous messages), I > object to this change. > > > Your objections seem to pertain to CSP. I've excluded CSP from the > proposal. > > Do you still object in some way? If so, why? > > > Adam also cited the Chromium WebKit > allowScriptFromSource/didNotAllowScript API. > > From looking at how it hooks into WebCore, it appears to require the > decision to execute a script to be dynamic, even when scripting is > generally disabled. > We implement a rule system (called content settings) where script execution (but also e.g. cookies) can be controlled depending on the security origin of the frame, and the security origin of the main frame. This allows for allow scripts from the main frame's security origin to run, while third-party scripts are blocked. FrameLoaderClient::allowScript implements this check. Now if the script is from a third-party, it might still be executed in the context of the main frame (because it was loaded via a <script> tag from a third-party site). This seems undesirable, and so we added allowScriptFromSource to control this behavior. didNotAllowScript is used to notify the browser that script execution was blocked. In that case, we show a small icon in the location bar which hopefully gives the user a hint at why everything is broken, and offers a quick option to enable javascript for this site. best -jochen > > Regards, > Maciej > > > _______________________________________________ > 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
