PR Request for Mixed Content

[mikewest]

Document title, URLs, estimated publication date

Mixed Content Level 1
https://www.w3.org/TR/mixed-content/

Abstract

This specification describes how a user agent should handle fetching of content over unencrypted or unauthenticated connections in the context of an encrypted and authenticated document.

Status

"""
This document was published by the Web Application Security Working Group as a Candidate Recommendation. This document is intended to become a W3C Recommendation. This document will remain a Candidate Recommendation at least until 2 September 2016 in order to ensure the opportunity for wide review. Normative changes since the prior CR publication are: 1. prefetch was incorrectly listed as optionally-blockable; 2. block-all-mixed-content reports; 3. There's an IANA registry now for CSP directives; and 4. We use "Is URL trustworthy?" rather than whitelisting "https" and "wss".

The (archived) public mailing list public-webappsec@w3.org (see instructions) is preferred for discussion of this specification. When sending e-mail, please put the text “mixed-content” in the subject, preferably like this: “[mixed-content] …summary of comment…”

Publication as a Candidate Recommendation does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

The entrance criteria for this document to enter the Proposed Recommendation stage is to have a minimum of two independent and interoperable user agents that implement all the features of this specification, which will be determined by passing the user agent tests defined in the test suite developed by the Working Group. The Working Group will prepare an implementation report to track progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 1 September 2015 W3C Process Document.

The following features are at-risk, and may be dropped during the CR period:

The passthrough request concept, and the related carveout in the blocking algorithms.
“At-risk” is a W3C Process term-of-art, and does not necessarily imply that the feature is in danger of being dropped or delayed. It means that the WG believes the feature may have difficulty being interoperably implemented in a timely manner, and marking it as such allows the WG to drop the feature if necessary when transitioning to the Proposed Rec stage, without having to publish a new Candidate Rec without the feature first.
"""

Link to group's decision to request transition

w3c/webappsec-mixed-content#15

Changes

• Editorial changes to align with changes in Fetch terminology.
• Dropping the "at risk" passthrough request concept, which no one implemented.

Requirements satisfied

No changes.

Dependencies met (or not)

No changes.

Wide Review

We've obtained substantially overlapping implementations in all major user agents, and had substantial engagement from folks across the board.

https://wpt.fyi/results/mixed-content?label=experimental&label=master&aligned

Issues addressed

https://github.com/w3c/webappsec-mixed-content/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aclosed+

Formal Objections

None.

Implementation

MIX1 is supported by default in all major user agents.

Patent disclosures

None.

[plehegar]

cc @wseltzer

[plehegar]

https://labs.w3.org/normative-references/check?url=https%3A%2F%2Fw3c.github.io%2Fwebappsec-mixed-content%2F

[plehegar]

https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FTR%2Fmixed-content%2F&doc2=https%3A%2F%2Fw3c.github.io%2Fwebappsec-mixed-content%2F

[swickr]

Transition approved.

Please update Section 6 to cite the replacement Fetch spec issue #235 and the WHATWG HTML LS section for Web Sockets. Also in that same section, RFC6455 has been updated; that citation should also be reviewed.

I am wondering if some of the open issues (e.g. #18 and #23 are really still open; the threads seems to have been abandoned and the spec seems to have been changed such that those issues may be obsolete.

[mikewest]

Please update Section 6 to cite the replacement Fetch spec issue #235 and the WHATWG HTML LS section for Web Sockets.

This change has actually already been made in HTML. I'll drop the reference entirely.

Also in that same section, RFC6455 has been updated; that citation should also be reviewed.

The citation is still reasonable. RFC8441 updates it with an HTTP/2 variant, but still relies on the same underlying algorithm. RFC8307 defines some .well-known endpoints, and RFC7936 clarifies registry procedures. http://www.rfc-editor.org/errata_search.php?rfc=6455&eid=4398 is still outstanding, and held for document update.

I am wondering if some of the open issues (e.g. #18 and #23 are really still open; the threads seems to have been abandoned and the spec seems to have been changed such that those issues may be obsolete.

I'll run through them again.

[plehegar]

friendly ping on this front. any help needed to publish?

[mikewest]

This fell off my radar. Will look into it tomorrow.

[plehegar]

Unless I'm mistaken, I believe this transition request has been abandoned. Feel free to re-open if needed.