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

Re: "Mixed Content" draft up for review.

From: Anne van Kesteren <annevk@annevk.nl>
Date: Mon, 2 Jun 2014 12:32:06 +0200
Message-ID: <CADnb78i=bwOEGRT6-eGaXuw=AH8wVCjf+F-nUa=vwO2pgPAZig@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Tanvi Vyas <tanvi@mozilla.com>, Brad Hill <bhill@paypal.com>, Dan Veditz <dveditz@mozilla.com>
On Fri, May 30, 2014 at 8:04 PM, Mike West <mkwst@google.com> wrote:
> https://w3c.github.io/webappsec/specs/mixedcontent/

You want to talk about something broader than document in the
introduction and maybe elsewhere. In particular service workers can
run without an associated document. If a service workers runs over TLS
(and there might be no alternative) it should not be able to get to
non-TLS resources.

Under "assumed secure origin" you should probably remove blob URLs.
They will get an origin and it will be the origin of the method that
created them. So they are not always secure, as they could be created
by an origin' whose scheme is http. Also, Chrome does not seem to
consider origins that are a globally unique identifier secure per
so maybe that should be removed entirely?

ISSUE 2: It seems like only <form method=POST> to an insecure origin
is actively harmful. GET would be the same as following a link.

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

ISSUE 5: We should coordinate with implementers whether this Fetch
hook should happen before HSTS or after HSTS. It seems there was some
misalignment around that. Also, it seems that if service workers are
TLS-only, the second note in this section only partially applies.

Also, for Fetch integration I would prefer if your hooks simply took a
request and a response (if necessary and available). The current setup
seems brittle. E.g. "Should response for client be blocked as mixed
content?" asks for a response and a request's client, but then somehow
gets hold of request's context! That's magic (or a crash). That also
allows future modifications to your algorithms more easily, if you
decide that you want to vary on more data. E.g. when request's context
is form you want to check request's method perhaps.

I'm happy to integrate these hooks after the above changes happened.
Or should I wait a bit longer until implementations have had a crack
at them? Might be good to get some implementer feedback too.

Received on Monday, 2 June 2014 10:32:35 UTC

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