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 <Jeff.Hodges@kingsmountain.com>
wrote:

> ###
>     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:
https://github.com/w3c/webappsec/commit/528162c3014ddd19cc6e04570fe19e57292ca0d1,
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
https://github.com/w3c/webappsec/commit/d9d8246bf985bcfe78d02dfb6d0c1be6ccb3b56a
.

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:
https://github.com/w3c/webappsec/commit/9b1690c0432e0320fa861c89ced452bbaf45a5ed
:)


>    "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 http://example.com/image.png is mixed content when loaded by
> https://not.example.com/."
>
> ..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:
https://github.com/w3c/webappsec/commit/8732a8402ba535dc7ab05423fec251f8ceb5c8bd


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

WDYT?

--
Mike West <mkwst@google.com>, @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
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)