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:34:54 +0100
Message-ID: <CAKXHy=eNZFpZuzqiJvFSVE3X4--32nhA3OgBq1uRv0E77=+w-A@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 8:30 PM, Brad Hill <hillbrad@gmail.com> wrote:
>
>
>> 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
>>
>> Yes, like that, but which cascades to descendant contexts.
>

It does cascade; it sets the document's flag, and nested browsing contexts
read that flag when they're created (or, that's what I intended
https://w3c.github.io/webappsec/specs/mixedcontent/#strict-nested-browsing-contexts
to express :)).


> I guess that would be implied by the iframe sandbox attribute which would
> be included-by-reference into CSP's sandbox directive.  It just seems ugly
> that you'd have to set a sandbox and christmas-tree the flags to get this
> behavior.  It also seems a bit out-of-pattern to add new flags to
> sandboxing in this way.  All the other flags loosen the sandbox.
>

I don't understand your point here. :/


> (this was probably a poor design choice from a forward evolution
> standpoint, now that I think about it, but that ship has sailed)
>

That was a poor design choice for future work, as it makes it virtually
impossible to add new sandbox flags. :/

-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:35:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:08 UTC