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

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

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.

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.

-Brad


On Mon Dec 15 2014 at 7:21:09 AM Mike West <mkwst@google.com> wrote:

> On Mon, Dec 15, 2014 at 12:10 PM, Mike West <mkwst@google.com> wrote:
>>
>> 3. Whether to change how currently-optionally-blockable mixed content
>>> in iframes is dealt with [4]--in particular, whether to treat all
>>> mixed content in iframes as mixed content--hasn't been adequately
>>> addressed. There doesn't seem to be sufficient agreement either way,
>>> and also we lack sufficient data to make a determination about the
>>> feasibility of making a change. My suggestion would be to note the
>>> issue as something to be resolved during CR/PR, if that can be done
>>> without prejudice against making the change to block it if we get data
>>> showing it is feasible.
>>>
>>
>> We ended up in
>> http://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0355.html;
>> I think it's totally reasonable to add something to frames that would
>> silently block all mixed content in any nested browsing context to give the
>> parent some assurance regarding the page's security indicator.
>>
>> I don't think this is something we could add at CR; it's really a new
>> feature. It's not clear to me that there's sufficient agreement on what we
>> should do here to proceed, but I'll draft some text that we can argue
>> about. :)
>>
>
> I took a pass at a strawman in
> https://w3c.github.io/webappsec/specs/mixedcontent/#strict-mode.
>
> WDYT?
>
> --
> 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.)
>
>