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

[MIX] Checking parent/top (Re: "Mixed Content" draft up for review.)

From: Mike West <mkwst@google.com>
Date: Tue, 3 Jun 2014 10:35:25 +0200
Message-ID: <CAKXHy=enzScaM2bFx=G35yEyGz4fdBPqd_5xTvtf99_Bt5aQpQ@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Tanvi Vyas <tanvi@mozilla.com>
On Tue, Jun 3, 2014 at 8:17 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> Again,
> https://w3c.github.io/webappsec/specs/mixedcontent/#categorize-environment
> step 1 says if the environment is TLS-protected, you return true. And
> you are not checking the parent in step 2 (which would not be reached
> if the current environment was secure), you check the top.

Ah, now I see your point. Sorry I missed it.

I think shortcutting when the current document is TLS-protected is
reasonable: that is, if I'm requesting `http://b.com` from `https://a.com`,
I don't have to look at the parent browsing context to know that I'm
working in a secure context. That's step 1.

If the current context is not TLS-protected (perhaps it's a 'data:' URL), I
need to look at my parent. But if I'm nested in multiple 'data:' URLs then
checking top might also be insufficient. Hrm.

Rather than trying to be clever about optimizing the spec's algorithm for
the minimum number of checks, I think I'll just change it to walk the
ancestor tree. If implementers have good ideas about how to optimize that
for speed, they're free to do so.



Received on Tuesday, 3 June 2014 08:36:14 UTC

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