W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2014

Re: Strict mixed content checking (was Re: MIX: Exiting last call?)

From: Mike West <mkwst@google.com>
Date: Mon, 15 Dec 2014 20:18:55 +0100
Message-ID: <CAKXHy=e11e6aBJbKLH8NjsRt+bj47EZY6S81K2=ny4gX+be8fA@mail.gmail.com>
To: Brad Hill <hillbrad@gmail.com>
Cc: Brian Smith <brian@briansmith.org>, Michael Cooper <cooper@w3.org>, David Walp <David.Walp@microsoft.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Mon, Dec 15, 2014 at 7:42 PM, Brad Hill <hillbrad@gmail.com> wrote:
> <hat=individual>
> I think that the iframe behavior as specified in this strawman is not
> ideal for the customers of this feature.
> My imagination of those customers is that they are mostly publishers and
> "content providers" who run 3rd-party ads on their site, and want to make
> sure that those ads aren't breaking their padlock.
> Unfortunately, the way ads are served many places is basically still in
> the stone age.  Publishers get a spreadsheet that lists ad placements,
> either as a <script> or <iframe> tag, which someone copy-pastes.  At best,
> this insertion is done automatically by some CMS.

In this scenario, the manually hard-coded embeds are almost certainly HTTP,
not HTTPS. They'll have to be manually modified somehow regardless if the
site wants to switch to HTTPS, right? Adding an attribute at the same time
doesn't seem like a ton to ask.

> Either way, forcing users to modify the attributes of the iframe tag they
> get from a 3rd-party supplier is much more difficult than setting a policy
> in a header that cascades to descendant contexts.  I know this is neither a
> good match for how non-sandbox policies work today in CSP, and neither is
> it a great fit to force a document to sandbox itself (even if weakly) in
> order to sandbox its descendants.  But I'm also not sure it makes sense to
> be able to force a descendant context into strict mode if you aren't strict
> (or even secure) yourself.

What's the risk? We already accept the (higher?) risk of sandbox turning
off script or other platform features a page might rely on. Given that we'd
already be blocking things like mixed script, the risk of not loading
images or videos seems like one we could easily swallow.

So my strawman would look more like a CSP directive or standalone header
> "strict-context-security" that applies to both the document and all
> descendant contexts.

There is a CSP directive defined in
https://w3c.github.io/webappsec/specs/mixedcontent/#strict-documents. Is
that more or less along the lines of what you're looking for?


Mike West <mkwst@google.com>, @mikewest

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
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Monday, 15 December 2014 19:19:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:44 UTC