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

Re: "Mixed Content" draft up for review.

From: Tanvi Vyas <tanvi@mozilla.com>
Date: Mon, 02 Jun 2014 14:26:17 -0700
Message-ID: <538CEBF9.4040404@mozilla.com>
To: Mike West <mkwst@google.com>, Anne van Kesteren <annevk@annevk.nl>
CC: "public-webappsec@w3.org" <public-webappsec@w3.org>, Brad Hill <bhill@paypal.com>, Dan Veditz <dveditz@mozilla.com>, Ryan Sleevi <rsleevi@chromium.org>, palmer@chromium.org
On 6/2/14 5:35 AM, Mike West wrote:
>     "Is document a secure browsing context?" This algorithm does not seem
>     to work how you want it to work. It seems first you want to get the
>     list of inclusive ancestors of a given document's associated browsing
>     context and then verify that for all of them the associated document
>     is TLS-protected. And only at that point do you want to return true.
> Checking the top-level resource is currently all that Chrome does. 
> Hopefully Tanvi can weigh in on Mozilla's implementation.
> That said, I don't think we need to traverse the entire chain if each 
> resource load checks its parent. The child frames should then be 
> transitively secure.
Mozilla's implementation checks the parent rather than top.  Similar to 
this example from the spec -
|http://a.com| frames |https://b.com|, which loads |http://evil.com|. In 
this case, the insecure request to |evil.com| will be blocked, as 
|b.com| was loaded over a secure connection, even though |a.com| was not.

As Mike says, we do not need to go up through the whole chain, as child 
frames are transitively secure.
Received on Monday, 2 June 2014 21:26:43 UTC

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