jochen at chromium.org
Tue Mar 19 11:52:55 PDT 2013
On Tue, Mar 19, 2013 at 11:42 AM, Maciej Stachowiak <mjs at apple.com> wrote:
> On Mar 19, 2013, at 11:12 AM, Geoffrey Garen <ggaren at 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
> 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
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev