- From: Mike West <mkwst@google.com>
- Date: Mon, 15 Dec 2014 20:18:55 +0100
- 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>
- Message-ID: <CAKXHy=e11e6aBJbKLH8NjsRt+bj47EZY6S81K2=ny4gX+be8fA@mail.gmail.com>
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 -- 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 Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Monday, 15 December 2014 19:19:45 UTC