Re: [webappsec] Rechartering: force secure-only child browsing contexts

On Mon, Nov 10, 2014 at 10:43 AM, Brad Hill <hillbrad@fb.com> wrote:
>   The essence of the request was, from sites that are https-only but
> include content from ad networks, "Don't allow anything in an iframe to
> break the top-level secure UI treatment that we have worked so hard to
> get."

What do people think of the following ideas?:

When optionally-blockable content is present directly in the main
document, continue to treat it as is currently specified in the Mixed
Content draft. However, when optionally-blockable content is present
indirectly in the document (e.g. in an iframe/frame/etc.) then treat
it as blockable content.

I hypothesize that an iframe with optionally-blockable mixed content
and no blockable mixed content that is needed to make the iframe
useful is rare. That is, I hypothesize that either the iframe will be
totally blocked because the iframe itself is mixed content, or the
iframe will be unusable because it probably has blockable mixed
content (probably scripts), or else the iframe is very unlikely to
have any optionally-blockable mixed content at all. Further, I
hypothesize that when the previous hypothesis is wrong, that the
iframe is probably an advertisement or other content that the user
considers superfluous and thus doesn't mind--or even prefers--being
blocked.

Further, I hypothesize that browsers' UIs for overriding mixed content
blocking is so hard to find/use that few users will trigger unblocking
of mixed content on the page for any reason, and especially because
we've blocked some image or video in an iframe that they want to see.

Further, I hypothesize that, for the cases where this policy would
truly be a net negative change for end users, the affected websites
are likely to quickly take corrective action to remedy the situation.
Thus, although there may be some small amount of user annoyance in the
beginning, most of that user annoyance will quickly dissipate.

Further, I hypothesize that this change will cause less inconvenience
for end-users than other planned changes such as the disabling of SSL
3.0.

Further, I hypothesize that by doing this, we'll be further
encouraging the deployment of TLS.

Further, by doing this automatically and unconditionally, we'll be
avoiding adding complexity to the web platform.

Further, by doing this automatically and unconditionally, we'd be
reducing the burden of the webappsec working group, so that the
working group can focus on other things.

Note that similar hypotheses were proven correct (AFAICT) for other
types of mixed content blocking that were enacted in recent history by
Google Chrome and Mozilla Firefox.

Thoughts?

Cheers,
Brian;

Received on Wednesday, 12 November 2014 06:06:33 UTC