W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2015

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

From: Mike West <mkwst@google.com>
Date: Mon, 19 Jan 2015 20:27:23 +0100
Message-ID: <CAKXHy=ccA2MTWt6-EfZDJt2cFV253V7-Je5NSpeHnPr8+CYPmg@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Cc: David Walp <David.Walp@microsoft.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Michael Cooper <cooper@w3.org>
On Mon, Jan 19, 2015 at 8:12 PM, Brian Smith <brian@briansmith.org> wrote:

> Mike West <mkwst@google.com> wrote:
> > I think that treating optionally blockable content in frames as blockable
> > would be a fine thing for vendors to experiment with.
>
> OK.
>
> Would adding a policy of "Content-Security-Policy:
> strict-mixed-content-checking" have any effects implicitly other than
> setting the strict mode flag? That is, would there any reason to not
> recommend that every web page (that doesn't intend to have mixed
> content) set a policy of "Content-Security-Policy:
> strict-mixed-content-checking"?
>

No, and no. Every website that cares should probably set this policy.

Another way of phrasing this question is "Is an empty policy
> equivalent to no policy?"
>

Yes.


> I'd like to suggest that you rename the directive to
> "no-mixed-content". I think "checking" in the name doesn't aid in
> comprehension and is just noise. I also think "no" would be clearer
> than "strict" in conveying the effects to a web developer who hasn't
> read the spec.
>

Sounds reasonable.

Any objections? Going once... going twice...

-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, 19 January 2015 19:28:15 UTC

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