Re: "Mixed Content" draft up for review.

On Mon, Jun 2, 2014 at 2:35 PM, Mike West <> wrote:
> On Mon, Jun 2, 2014 at 12:32 PM, Anne van Kesteren <> wrote:
>> 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.
> That makes sense. Does "execution context" capture "Document or Global
> Scope"? Or is there some term that's more applicable?

HTML uses "JavaScript global environment" and then has "document
environment", "dedicated worker environment", "shared worker
environment", and "worker environment" (former two combined) as

>> 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.
> Hrm. A blob constructed from an HTTP resource wouldn't touch the network
> when loading; it would be just as secure as the rest of the page. As long as
> restrictions are in place that lock blobs to their own origins, they can be
> safely considered just as secure as 'data:', etc.

Right, so if the environment is non-TLS, the blob is not secure.

>> Also, Chrome does not seem to
>> consider origins that are a globally unique identifier secure per
>> so maybe that should be removed entirely?
> Chrome certain allows HTTPS pages to load 'data:' URLs at the moment. I
> think there's been some discussion around whether or not we need to do some
> sort of taint checking before doing so (similar to Canvas). I'm hoping to
> avoid that entirely by simply blocking the mechanisms currently available
> for grabbing insecure data (XHR, EventSource, WebSockets, etc).

I see what you mean. But that means blob/data inherit the security.
They are not secure by themselves. E.g. if I navigate to a data URL,
that does not mean the environment it creates is secure.

>> 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.
> I disagree. Links don't have a mechanism for soliciting information from the
> user that the page doesn't already know, nor do they generally (assuming
> sanity...) contain capability-bearing nonces. (very bad without TLS though)

> Those are the problem, not the
> method used to transmit the data. If it's compatible with the web at large
> to treat HTTP-targeting forms as mixed content, we should do it for all form
> submissions, regardless of action.

Fair enough I guess.

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

True, and the same goes for only checking top. However, the current
algorithm does not do that. It returns as soon it verifies the current

>> 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.
> I believe that both Chrome and Firefox currently implement the opposite of
> what's specced here (e.g. mixed content happens, then HSTS happens). I think
> that the relevant folks consider that a bug, but I'd invite Ryan and Chris
> to weigh in (Hi Ryan and Chris, who I just added to CC!). If I've
> misinterpreted things, I'm happy to change that piece.

Okay, in the placeholder
hook is after HSTS.

>> Also, for Fetch integration I would prefer if your hooks simply took a
>> request and a response (if necessary and available).
> Yup, that makes a lot of sense.

Looks good.


Received on Monday, 2 June 2014 12:55:37 UTC