Re: "Mixed Content" draft up for review.

Thanks, Anne, this is very helpful feedback.

On Mon, Jun 2, 2014 at 12:32 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

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

That makes sense. Does "execution context" capture "Document or Global
Scope"? Or is there some term that's more applicable?


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

Also, Chrome does not seem to
> consider origins that are a globally unique identifier secure per
>
> https://sites.google.com/a/chromium.org/dev/Home/chromium-security/security-faq
> 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).

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

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


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


> 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.
https://github.com/w3c/webappsec/commit/21ecb452df370ed37ad1de8d8ed69c499b8ae525

WDYT?

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

Probably best to wait a bit since no one else in the WG has given feedback.
I've gone over the doc with the Chrome security folks, so I'm halfway
confident that it matches our intentions, but it would be best to get other
implementers on board before going too much further.

-mike