Re: some brief comments on mixedcontent

Thank you for this detailed feedback, Jeff, and apologies that I took 3
months to address it.  Responses inline. :)

On Tue, Mar 17, 2015 at 5:02 PM, =JeffH <>

> ###
>     NOTE:  "Mixed content" as used above (see also Section 5.3 in
>            [W3C.REC-wsc-ui-20100812]) refers to the notion termed "mixed
>            security context" in this specification and should not be
>            confused with the same "mixed content" term used in the
>            context of markup languages such as XML and HTML.
> ###
> So anyway, I realize that given how embedded the term "mixed contect" is in
> the web security world that it isn't going to be changed. however, I do
> suggest trying to disambiguate and clarify it in a spec such as
> mixedcontent.  e.g., I'd be tempted to add a subtitle of "mixed security
> context", and/or a disclaimer similar to the note above from RFC6797 that
> clarifies it as distinct from the notion in the markup language world.

Noted this in:,
and added a brief discussion of "mixed security context" in order to
clarify the UI requirements below. I don't believe this is a normative
change from the previous text: the outcome should be the same.

> Also, [WSC-UI] is a Recommendation, and it clearly defines 'mixed content'
> [3] --- and mixedcontent [*] is clearly re-defining the term without
> reference to [WSC-UI]. I don't know how the W3C deals with one spec
> "updating" another (as is done in the IETF), but without resolution, it's a
> loose end (from my perspective anyway).

Noted this in

in terms of the Note at the end of the Introduction in [*], you might want
> to s/more a user agent/more user agents/.
> FWIW, the earliest mentions of "Downloading non-secure content from a
> secure
> web site.." wrt IE that I can find refer to IE 6, and perhaps IE 5 or 5.5
> (yes, i poked around the internet archive too). I could not find any
> references to IE 4.

Fixed the typos and added sources:

>    "A resource is said to be mixed content if the resource’s origin is
> insecure, and the context responsible for loading it restricts mixed
> content."
> ..seems a bit awkward in that the resource isn't going to be loaded if the
> loading context restricts such loads.
> And the example..
>    "The image is mixed content when loaded by
> ..seems odd because it talks about "when loaded", but mixed content is
> detected prior to loads in the case of a priori insecure (origin | url), or
> in the act of establishing a TLS connection and discovering that the
> resultant TLS-protection is deprecated.

I've addressed this differently than you suggested by widening the
definition of "mixed content" to include both requests and resources. This
was implicit in the way I was using the term already, so I don't believe it
introduces any normative changes in the document:

> wrt "security considerations" I would add an item briefly discussing that
> being careful/strict about 'mixed content' is only protecting against
> attackers on the wire -- it does nothing to protect the requester if any of
> the servers involved in serving the resource being fetched are themselves
> surreptitiously compromised.  this is a point often neglected it seems.

I've poked at this in


Mike West <>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Received on Monday, 22 June 2015 13:51:48 UTC