Re: "Mixed Content" draft up for review.

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

> On Mon, Jun 2, 2014 at 2:35 PM, Mike West <mkwst@google.com> wrote:
> > On Mon, Jun 2, 2014 at 12:32 PM, Anne van Kesteren <annevk@annevk.nl>
> 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
> classifications.
>

Thanks, I'll run with that.

https://github.com/w3c/webappsec/commit/a62fe8f8084f6d16de8f900e4cf50446e4ce69f1#diff-797d64e19b34e971e000935ac95e9255

WDYT?


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

Right. But it also wouldn't load due to origin restrictions.


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

Indeed. Navigating to a 'data:' (or 'blob:') URL would not be
"TLS-protected", and wouldn't create a "secure context" as currently
defined in the spec. We wouldn't do mixed content checking on resources
loaded from those URLs (unless they are nested in a secure context, in
which case we would, because they are secure by transitivity).


> > 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.
>
> http://www.w3.org/TR/capability-urls/ (very bad without TLS though)
>

I'd prefer to imagine that those don't exist.

I'd also prefer to treat navigations as mixed content, but I think it would
break the web. Scoping the breakage to forms seems more reasonable. :)


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

I think we need both. Consider http://a.com -> https://b.com -> data: ->
http://c.com

Before loading c, we check the parent, which is a secure context because of
b.com. If we only checked a.com, we'd allow c.com to load. I don't think we
want that.

-mike