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

I think this is a pretty reasonable concept to add to MIX.

It's not clear to me whether it should be the default behavior, or whether
it should be opted-into (similar to `sandbox`). Either way, it seems like a
good mechanism by which existing sites can start migrating their content to
HTTPS without fear of degraded UI due to third-party content.

I know Ryan has thought about similar topics in the past. CCing him here
for thoughts.

-mike

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

On Wed, Nov 12, 2014 at 7:06 AM, Brian Smith <brian@briansmith.org> wrote:

> 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;
>
>