El mar, 22-07-2014 a las 15:13 -0500, Michael Catanzaro escribió: > Hi, > > I'm an intern with Igalia, working on adding active mixed content > blocking in Epiphany. Background: WebKit already has a mixed content > checker that allows browsers to decide whether they want to allow > displaying passive mixed content or allow running active mixed content. > All are allowed by default. For a good summary of what mixed content is, > see [1] or [2]. (For Epiphany, I plan to block active mixed content and > only display a warning icon for passive mixed content, since this is > what major browsers do.) > > I doubt we want to turn on mixed content blocking unconditionally, so we > need some new API in WebKitGTK+ to allow browsers to configure this. > I've implemented two obvious possibilities: > > Possibility 1: Just directly expose the existing internal preferences > with WebKitSettings. WebKitSettings would gain two new properties, > allow-display-of-insecure-content and allow-running-of-insecure-content, > plus associated getters/setters. > > The disadvantage of Possibility 1 is that it's not a good parallel to > webkit_web_context_[gs]et_tls_errors_policy(), and this would not allow > browsers to override the policy on a per-page basis. For example, > Firefox and Chromium both allow reloading the current page with insecure > context enabled if you click an icon in the address bar.
I would say it's rather the opposite, because WebKitSettings are per page (view), it's also true that in ephy we use a single WebKitSettings object shared by all web views, so in practice you are right that we would end up enabling/disabling it globally. WebKitWebContext applies to all web views sharing the same web process, so in single process model, it would be global too. > Possibility 2: Introduce a new enum, WebKitInsecureContentPolicy: > > WEBKIT_INSECURE_CONTENT_POLICY_ALLOW_ALL, > WEBKIT_INSECURE_CONTENT_POLICY_ALLOW_DISPLAY, > WEBKIT_INSECURE_CONTENT_POLICY_ALLOW_NONE > > (It's trivial to also add WEBKIT_INSECURE_CONTENT_POLICY_ALLOW_RUNNING, > but no sane browser would want to block mixed passive content and not > mixed active content, so I think we should just omit this.) > > I propose three associated functions: > > * webkit_web_context_[gs]et_insecure_content_policy(), > * webkit_web_view_reload_with_insecure_content_policy() > > A browser could then set a default policy and also allow the user to > change the policy for the current web page if content is blocked, which > it can detect with the existing WebKitWebView::insecure-content-detected > signal. We haven't decided if we want to do this in Epiphany, but since > it's how other major browsers work I think WebKitGTK+ should make this > easy regardless. > > Does this API seem good? If so, I will open a bug with a patch. Looks a bit weird to me that one function is in web context and the other in web view, maybe we can have: webkit_web_context_[gs]et_insecure_content_policy() webkit_web_context_[gs]et_insecure_content_policy_for_uri() > There is one other minor problem: WebKit currently treats frames as > passive content, since this is what Chromium originally did, but > nowadays all major browsers treat frames as active content. Would it be > permissible to change this in WebCore, so that the > allow-running-insecure-content setting is checked to decide whether to > block a frame, rather than the allow-display-of-insecure-content > setting? I think no ports currently allow mixed content blocking (it was > used by Chromium), so we probably have free reign to make changes here? You could open a bug suggesting that change or propose it in webkit-dev mailing list. > Happy Tuesday, > > Michael Catanzaro > > [1] > https://community.qualys.com/blogs/securitylabs/2014/03/19/https-mixed-content-still-the-easiest-way-to-break-ssl > [2] > https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/ > > -- Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3
signature.asc
Description: This is a digitally signed message part
_______________________________________________ webkit-gtk mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-gtk
