Source: https://w3c.github.io/webappsec-mixed-content/
Timestamp: 2019-04-19 22:37:12+00:00

Document:
5.1 Does settings prohibit mixed security contexts?
5.2 Should fetching request be blocked as mixed content?
5.3 Should response to request be blocked as mixed content?
A request is mixed content if its url is not a priori authenticated, and the context responsible for loading it requires prohibits mixed security contexts (see §5.1 Does settings prohibit mixed security contexts? for a normative definition of the latter).
A response is mixed content if it is an unauthenticated response, and the context responsible for loading it requires prohibits mixed security contexts.
url is a potentially trustworthy URL [SECURE-CONTEXTS].
Note: We special case data URLs here, as we don’t consider them particularly trustworthy, but we also don’t wish to block them as mixed content, as they never hit the network.
response’s url is a priori authenticated.
If response’s url’s scheme is "https" or "wss", response’s HTTPS state is "modern".
Given a Document A, the embedding document of A is the Document through which A’s browsing context is nested [HTML].
Mixed content is optionally-blockable when the risk of allowing its usage as mixed content is outweighed by the risk of breaking significant portions of the web. This could be because mixed usage of the resource type is sufficiently high, and because the resource is low-risk in and of itself. The fact that these resource types are optionally-blockable does not mean that they are safe, simply that they’re less catastrophically dangerous than other resource types. For example, images and icons are often the central UI elements in an application’s interface. If an attacker reversed the "Delete email" and "Reply" icons, there would be real impact to users.
Requests whose initiator is the empty string, and whose destination is "image".
Note: This corresponds to most images loaded via img (including SVG documents loaded as images, as those are blocked from executing script or fetching subresources) and CSS (background-image, border-image, etc). It does not include img elements that use srcset or picture.
Requests whose destination is "video".
Note: This corresponds to video loaded via video and source.
Requests whose destination is "audio".
Note: This corresponds to audio loaded via audio and source.
We further limit this category in §5.2 Should fetching request be blocked as mixed content? by force-failing any CORS-enabled request. This means, for example, that mixed content images loaded via <img crossorigin ...> will be blocked. This is a good example of the general principle that content falls into this category only when it is too widely used to be blocked outright. The Working Group intends to carve out more blockable subsets as time goes on.
Any mixed content that is not optionally-blockable as defined above is considered to be blockable. Typical examples of this kind of content include scripts, plugin data, data requested via XMLHttpRequest, and so on.
Note: Navigation requests might target top-level browsing contexts; these are not considered mixed content. See §5.2 Should fetching request be blocked as mixed content? for details.
Note: Note that requests made on behalf of a plugin are blockable. We recognize, however, that user agents aren’t always in a position to mediate these requests. NPAPI plugins, for instance, often have direct network access, and can generally bypass the user agent entirely. We recommend that user agents block these requests when possible, and that plugin vendors implement mixed content checking themselves to mitigate the risks outlined in this document.
To this end, Document objects and browsing contexts have a strict mixed content checking flag which is set to false unless otherwise specified. This flag is checked in both §5.2 Should fetching request be blocked as mixed content? and §5.3 Should response to request be blocked as mixed content? to determine whether the Document is in strict mode.
Note: Strict mixed content checking is inherited by embedded content; if a page opts into strict mode, framed pages will be prevented from loading mixed content, as described in §4.4 Inheriting an opt-in.
ensure that these requirements are applied to any Document in a nested browsing context, as described in §4.4 Inheriting an opt-in.
Authors may opt a Document into strict mixed content checking via a block-all-mixed-content Content Security Policy directive [CSP3], defined via the following ABNF grammar.
This directive will trigger violation reports for mixed content on a page. Details are found in §5.2 Should fetching request be blocked as mixed content?.
If policy’s disposition is not "enforce", then abort this algorithm.
Set context’s strict mixed content checking flag to true.
When initializing a new Document object, set its strict mixed content checking flag to true if its browsing context’s strict mixed content checking flag is true.
Fetch calls the algorithm defined in §5.2 Should fetching request be blocked as mixed content? at the top of the fetching algorithm in order to block network traffic to URLs which are not a priori authenticated [FETCH]. Hooking into Fetch here ensures that we catch not only the initial request, but all redirects as well.
Further, Fetch calls the algorithm defined in §5.3 Should response to request be blocked as mixed content? at the bottom of the fetching algorithm in order to block unauthenticated responses. This hook is necessary to detect resources modified or synthesized by a ServiceWorker, as well as to determine whether a response is unauthenticated once the TLS-handshake has finished. See steps 4.1 and 4.2 of the algorithm defined in §5.3 Should response to request be blocked as mixed content? for detail.
The algorithm defined in §5.1 Does settings prohibit mixed security contexts? is used by both §5.2 Should fetching request be blocked as mixed content? and §5.3 Should response to request be blocked as mixed content?, as well as §6 Modifications to WebSockets in order to determine whether an insecure request ought to be blocked.
5.1. Does settings prohibit mixed security contexts?
Both documents and workers have environment settings objects which may be examined according to the following algorithm in order to determine whether they restrict mixed content. This algorithm returns "Prohibits Mixed Security Contexts" or "Does Not Prohibit Mixed Security Contexts", as appropriate.
If settings’ HTTPS state is not "none", then return "Prohibits Mixed Security Contexts".
Set document to document’s embedding document.
Let embedder settings be document’s global object's relevant settings object.
If embedder settings’ HTTPS state is not "None", then return "Prohibits Mixed Security Contexts".
Return "Does Not Restrict Mixed Security Contexts".
https://a.com frames a data: URL, which loads http://evil.com. In this case, the insecure request to evil.com will be blocked, as a.com was loaded over a secure connection, even though the framed data: URL would not block mixed content if loaded in a top-level context.
5.2. Should fetching request be blocked as mixed content?
§5.1 Does settings prohibit mixed security contexts? returns "Does Not Restrict Mixed Security Contexts" when applied to request’s client.
request’s url is a priori authenticated.
request’s destination is "document", and request’s target browsing context has no parent browsing context.
Note: We exclude top-level navigations from mixed content checks, but user agents MAY choose to enforce mixed content checks on insecure form submissions (see §7.5 Further Action).
Let violation be the result of executing the algorithm defined in Content Security Policy §2.3.1 Create a violation object for global, policy, and directive on request’s client’s global object, policy, and "block-all-mixed-content".
Set violation’s resource to request’s url.
Execute the algorithm defined in Content Security Policy §5.3 Report a violation on violation.
request’s destination is "image", and initiator is not "imageset".
5.3. Should response to request be blocked as mixed content?
Note: If a request proceeds, we still might want to block the response based on the state of the connection that generated the response (e.g. because the request is blockable, but the connection is unauthenticated), and we also need to ensure that a Service Worker doesn’t accidentally return an unauthenticated response for a blockable request. This algorithm is used to make that determination.
§5.1 Does settings prohibit mixed security contexts? returns Does Not Restrict Mixed Content when applied to request’s client.
If secure is false, and the algorithm in §5.1 Does settings prohibit mixed security contexts? returns "Restricts Mixed Security Context" when applied to client’s global object’s relevant settings object, then the client MUST fail the WebSocket connection and abort the connection [RFC6455].
If secure is true, and the TLS handshake performed in step 5 results in an HTTPS state of "deprecated", then the client MUST fail the WebSocket connection and abort the connection [RFC6455].
These changes together mean that we’ll no longer throw a SecurityError exception directly upon constructing a WebSocket object, but will instead rely upon blocking the connection and triggering the fail the WebSocket connection algorithm, which developers can catch by hooking a WebSocket object’s onerror handler. This is consistent with the behavior of XMLHttpRequest, EventSource, and fetch().
If §5.1 Does settings prohibit mixed security contexts? returns Restricts Mixed Content when applied to a Document's relevant settings object, then a user agent MAY choose to warn users of the presence of one or more form elements with action attributes whose values are not a priori authenticated URLs.

References: §5
 §5
 §5
 §5
 §5
 §4
 §4
 §5
 §5
 §5
 §5
 §5
 §5
 §5
 §6

§5
 §7
 §2
 §5

§5
 §5
 §5