[webkit-gtk] Mixed content blocking

[Carlos Garcia Campos]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <https://lists.webkit.org/pipermail/webkit-gtk/attachments/20140722/7d741e13/attachment.sig>