Mixed Content

W3C Candidate Recommendation,

This version:
https://www.w3.org/TR/2016/CR-mixed-content-20160802/
Latest published version:
https://www.w3.org/TR/mixed-content/
Editor's Draft:
https://w3c.github.io/webappsec-mixed-content/
Previous Versions:
https://www.w3.org/TR/2015/CR-mixed-content-20151008/
Version History:
https://github.com/w3c/webappsec-mixed-content/commits/master/index.src.html
Feedback:
public-webappsec@w3.org with subject line “[mixed-content] … message topic …” (archives)
Editor:
(Google Inc.)
Participate:
File an issue (open issues)

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 of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

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

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

1. Introduction

This section is not normative.

When a user successfully loads a resource from example.com over a secure channel (HTTPS, for example), the user agent is able to make three assertions critical to the user’s security and privacy:

Together, these assertions give the user some assurance that example.com is the only entity that can read and respond to her requests (caveat: without shocking amounts of work) and that the bits she’s received are indeed those that example.com actually sent.

The strength of these assertions is substantially weakened, however, when the encrypted and authenticated resource requests subresources (scripts, images, etc) over an insecure channel. Those resource requests result in a resource whose status is mixed, as insecure requests are wide open for man-in-the-middle attacks. This scenario is unfortunately quite common.

This specification details how a user agent can mitigate these risks to security and privacy by limiting a resource’s ability to inadvertently communicate in the clear.

Note: Nothing described in this document is really new; everything covered here has appeared in one or more user agents over the years: Internet Explorer led the way, alerting users to mixed content since around version 4.

2. Key Concepts and Terminology

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.

Inside a context that restricts mixed content (https://secure.example.com/, for example):
  1. A request for the script http://example.com/script.js is mixed content. As script requests are blockable, the user agent will return a network error rather than loading the resource.

  2. A request for the image http://example.com/image.png is mixed content. As image requests are optionally-blockable, the user agent might load the image, in which case the image resource itself would be mixed content.

If mixed content is loaded into a context that restricts mixed content (as in #2 above), that context is considered a mixed security context (as defined in [RFC6797]).

Note: "Mixed content" was originally defined in section 5.3 of [WSC-UI]. This document updates that initial definition.

Note: [XML] also defines an unrelated "mixed content". concept. This is potentially confusing, but given the term’s near ubiquitious usage in a security context across user agents for more than a decade, the practical risk of confusion seems low.

a priori authenticated URL
We know a priori that a request to a particular URL (url) will be delivered in a way that mitigates the risks of interception and modifications if either of the following statements is true:
  1. The algorithm defined in Secure Contexts §is-url-trustworthy returns "Potentially Trustworthy" when executed upon url [SECURE-CONTEXTS].

  2. url’s scheme is "data".

    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.

unauthenticated response
We know a posteriori that a response (response) is unauthenticated if both of the following statements are true:
  1. response’s url is a priori authenticated.

  2. If response’s url’s scheme is "https" or "wss", response’s HTTPS state is "modern".

embedding document
Given a Document A, the embedding document of A is the Document through which A’s browsing context is nested [HTML51].

3. Content Categories

In a perfect world, each user agent would be required to block all mixed content without exception. Unfortunately, that is impractical on today’s Internet; a user agent needs to be more nuanced in its restrictions to avoid degrading the experience on a substantial number of websites.

With that in mind, we here split mixed content into two categories: §3.1 Optionally-blockable Content and §3.2 Blockable Content.

Note: Future versions of this specification will update this categorization with the intent of moving towards a world where all mixed content is blocked; that is the end goal, but this is the best we can do for now.

3.1. Optionally-blockable Content

A resource or request 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.

This category of content includes:

  • Images loaded via img or CSS (background-image, border-image, etc)

    Note: This includes SVG documents loaded as images, as they are banned from executing script or loading subresources. It does not include images loaded via picture.

  • Video loaded via video and source
  • Audio loaded via audio and source

Note: We further limit this category in §5.3 Should fetching request be blocked as mixed content? by force-failing any CORS-enabled request. This means 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.

3.2. Blockable Content

Any resource or request that isn’t optionally-blockable is 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.3 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 plugin vendors implement mixed content checking themselves to mitigate the risks outlined in this document.

4. Strict Mixed Content Checking

In order to give authors assurance that mixed content will never degrade the security UI presented to their users (as described in §7.3 UI Requirements), authors may choose to enable a stricter variant of mixed content checking which will both block optionally-blockable and blockable mixed content, and suppress the user override options discussed in §7.4 User Controls.

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.3 Should fetching request be blocked as mixed content? and §5.4 Should response to request be blocked as mixed content? to determine whether the Document is in strict mode.

A Document may opt itself into strict mode by either delivering a Content-Security-Policy HTTP header, like:
Content-Security-Policy: block-all-mixed-content

or by embedding the policy in a meta element, like:

<meta http-equiv="Content-Security-Policy"
      content="block-all-mixed-content">

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.3 Inheriting an opt-in.

4.1. Effects

If a Document's strict mixed content checking flag is set to true, the user agent MUST:

  1. treat optionally-blockable mixed content as though it were blockable.
  2. NOT provide users with a mechanism for forcing blockable mixed content to load.

    Note: This requirement overrides the suggestion in §7.4 User Controls.

  3. NOT provide any user-facing indication that mixed content is present.

    Note: This requirement overrides the suggestion in §7.3 UI Requirements, which is safe to do since the combination of the first and second requirements above ensure that mixed content will never load in this page’s context.

    Note: This requirement does not include developer-facing indicators such as console messages.

  4. ensure that these requirements are applied to any Document in a nested browsing context, as described in §4.3 Inheriting an opt-in.

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

directive-name  = "block-all-mixed-content"
directive-value = ""

When enforcing the block-all-mixed-content directive, set the protected resource’s strict mixed content checking flag to true.

This directive will trigger violation reports for mixed content on a page. Details are found in §5.3 Should fetching request be blocked as mixed content?.

Note: A similar effect may be achieved on a more granular level by setting individual directives. For example img-src https: would prevent insecure images from loading.

4.3. Inheriting an opt-in

If a Document's strict mixed content checking flag is set, the user agent MUST ensure that all nested browsing contexts inherit the setting in the following ways:

  1. When a nested browsing context context is created, set its strict mixed content checking flag to true if context’s embedding document’s strict mixed content checking flag is set to true.
  2. 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.

5. Insecure Content in Secure Contexts

At a high level, the following algorithms allow user agents to determine whether particular requests should succeed, or should result in network errors.

Fetch calls the algorithm defined in §5.3 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.4 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.4 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.3 Should fetching request be blocked as mixed content? and §5.4 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.

Given an environment settings object (settings):

  1. If settingsHTTPS state is not "none", then return "Prohibits Mixed Security Contexts".

  2. If settings has a responsible document document, then:

    1. While document has an embedding document:

      1. Set document to document’s embedding document.

      2. Let embedder settings be document’s global object’s relevant settings object.

      3. If embedder settingsHTTPS state is not "None", then return "Prohibits Mixed Security Contexts".

  3. Return "Does Not Restrict Mixed Security Contexts".

If a document has an embedding document, a user agent needs to check not only the document itself, but also the top-level browsing context in which the document is nested, as that is the context which controls the user’s expectations regarding the security status of the resource she’s loaded. For example:
http://a.com loads http://evil.com. The insecure request will be allowed, as a.com was not loaded over a secure connection.
https://a.com loads http://evil.com. The insecure request will be blocked, as a.com was loaded over a secure connection.
http://a.com frames https://b.com, which loads http://evil.com. In this case, the insecure request to evil.com will be blocked, as b.com was loaded over a secure connection, even though a.com was not.
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. Is request a passthrough request?

A passthrough request is a request (request) which is created in a browsing context (e.g. via an img tag in a document), but serviced by a Service Worker (e.g. by calling fetch(e.request) from within an onfetch event handler). As described in §7.5 Service Workers, we special-case these kinds of requests in order to allow web developers to layer service workers on top of an existing site which relies on requesting optionally-blockable mixed content.

More formally, request is a passthrough request if the following conditions hold [FETCH]:

  1. request’s initiator is fetch

    Note: When a request is copied (as in the fetch(e.response) example above), the original context is lost. Here, we ensure that we’re dealing with such a request, but we implicitly rely on §5.3 Should fetching request be blocked as mixed content? preventing blockable requests from entering a Service Worker in the first place.

  2. request’s window is an environment settings object (and, therefore, not no-window)

    Note: We rely on the window property being properly set by [FETCH] to the environment settings object responsible for the request in order to ensure that we can render some sort of warning to the user (as described in §7.3 UI Requirements).

  3. request’s client’s global object is a ServiceWorkerGlobalScope object.

    Note: We rely on the client property to reflect the origin of the request. Importantly, request is only a passthrough request if it originated inside a Service Worker.

5.3. Should fetching request be blocked as mixed content?

Note: The Fetch specification hooks into this algorithm to determine whether a request should be entirely blocked (e.g. because the request is for blockable content, and we can assume that it won’t be loaded over a secure connection).

Given a Request request, a user agent determines whether the Request request should proceed or not via the following algorithm:

  1. Return allowed if one or more of the following conditions are met:
    1. §5.1 Does settings prohibit mixed security contexts? returns "Does Not Restrict Mixed Security Contexts" when applied to request’s client.
    2. request’s url is a priori authenticated.
    3. The user agent has been instructed to allow mixed content, as described in §7.4 User Controls).
    4. 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.6 Further Action).

  2. For each policy in request’s client’s CSP list:
    1. If policy’s directive set contains a directive whose name is "block-all-mixed-content":

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

      2. Set violation’s resource to request’s url.

      3. Execute the algorithm defined in Content Security Policy §5.3 Report a violation on violation.

  3. Return blocked if one or more of the following conditions are met:
    1. The user agent is configured to block optionally-blockable mixed content, as described in §7.4 User Controls.
    2. request’s client’s strict mixed content checking flag is true.
    3. request’s mode is CORS or CORS-with-forced-preflight.
  4. Return allowed if one or more of the following conditions are met:
    1. request’s initiator is "fetch" and destination is "subresource", and request is a passthrough request.
    2. request’s type is "image", and initiator is not "imageset".
    3. request’s type is "video".
    4. request’s type is "audio".
  5. Return blocked.

Note: We special-case fetch to allow it as optionally-blockable in the event that a Service Worker is making a no-cors request in response to a Fetch event generated from a Document. In that case, the request’s client property will be an environment settings object whose global object is a Window object (the Service Worker’s request’s client, on the other hand, will be a WorkerGlobalScope object.

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

Given a request request and response response, the user agent determines what response should be returned via the following algorithm:

  1. Return allowed if one or more of the following conditions are met:
    1. §5.1 Does settings prohibit mixed security contexts? returns Does Not Restrict Mixed Content when applied to request’s client.
    2. response’s HTTPS state is modern.
    3. The user agent has been instructed to allow mixed content, as described in §7.4 User Controls).
    4. 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.6 Further Action).

  2. Return blocked if one or more of the following conditions are met:
    1. The user agent is configured to block optionally-blockable mixed content, as described in §7.4 User Controls.
    2. request’s client’s strict mixed content checking flag is true.
  3. Return allowed if response is an opaque filtered response and one or more of the following conditions are met:
    1. request’s initiator is "fetch", and request is a passthrough request.
    2. request’s type is "image", and initiator is not "imageset".
    3. request’s type is "video".
    4. request’s type is "audio".
  4. Return blocked.

6. Modifications to WebSockets

The WebSocket() constructor algorithm [WEBSOCKETS] is modified as follows:

Note: This suggestion is filed as bug #28841 against [WEBSOCKETS].

The Establish a WebSocket Connection algorithm [RFC6455] is modified as follows:

  1. After the current step 1, perform the following step:

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

  2. After the current step 5, perform the following step:

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

      This is super hand-wavey.

Note: Filed as errata #4398 against [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.

7. Security and Privacy Considerations

7.1. Limitations

Blocking mixed content allows us to ensure that the guarantees discussed in §1 Introduction are upheld. Note, however, that those guarantees only protect developers and users against active network attackers who would otherwise be able to replace critical bits of code or content on the wire as it flows past. They do not protect against a compromised server that itself is coerced into sending corrupted resources.

Mechanisms such as Subresource Integrity [SRI] are designed to deal with this kind of threat, and we recommend that web developers make use of them whenever possible.

7.2. Form Submission

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.

Note: Chrome, for example, currently gives the same UI treatment to a page with an insecure form action as it does for a page that displays an insecure image.

Further, a user agent MAY treat form submissions from such a Document as a blockable request, even if the submission occurs in the top-level browsing context.

7.3. UI Requirements

If a user agent would normally indicate to the user that the top-level browsing context is secure, then:

If a mixed content indication is present, it MUST be made available through accessibility APIs for users of assistive technologies.

Note: This requirement holds even in the context of an EV status [CAB]. An EV certificate’s indicator does not override the necessity to notify users of mixed content violations.

7.4. User Controls

A user agent MAY offer users the ability to directly decide whether or not to treat all mixed content as blockable (meaning that even optionally-blockable mixed content would be blocked).

Note: It is strongly recommended that users take advantage of such an option if provided.

A user agent MAY offer users the ability to override its decision to block blockable mixed content on a particular page.

Note: Practically, a user agent probably can’t get away with not offering such a back door. That said, allowing mixed script is in particular a very dangerous option, and each user agent REALLY SHOULD NOT [RFC6919] present such a choice to users without careful consideration and communication of the risk involved.

Any such controls offered by a user agent MUST also be offered through accessibility APIs for users of assistive technologies.

7.5. Service Workers

The fact that Service Workers sit inbetween a document and the network means that we need to special-case requests made in those contexts. In particular, they should be able to cache the results of insecure requests, provided that those requests were triggered from a document (which, presumably, ensures that they’ll be used in an optionally-blockable context). Those insecure results, however, cannot be exposed to the Service Worker, nor should the Service Worker be allowed to launder responses to optionally-blockable requests into responses to blockable requests.

To that end:

  1. §5.3 Should fetching request be blocked as mixed content? has some carve-outs for the fetch request initiator, with the intent of allowing a Service Worker to copy a request as part of its response to a Fetch event (e.g. fetch(event.response) should be executable inside the event handler.

    fetch will continue to be treated as blockable when executed outside the context of a Fetch event, which of course includes document contexts.

  2. §5.4 Should response to request be blocked as mixed content? verifies that the incoming response has the same security characteristics that were allowed for the request. That is, a Service Worker will not be able to replace a request for a secure script with a cached response for an insecure resource.

7.6. Further Action

A user agent is encouraged to take further action above and beyond the requirements this document outlines in order to discourage developers from embedding mixed content.

For instance, a user agent could:

  1. Interpret the presence of a Strict-Transport-Security header field as forcing all content into the blockable category [RFC6797], or as a signal to enable strict mode for mixed content checking.
  2. Modify requests for optionally-blockable resources which are mixed content in order to reduce the risk to users: cookies and other authentication tokens could be stripped from the requests, automatic scheme upgrades could be attempted, and so on.
  3. Treat optionally-blockable resources inside nested browsing contexts as blockable, to allow sites to embed resources without fear of introducing mixed content.

8. IANA Considerations

The Content Security Policy Directive registry should be updated with the following directives and references [RFC7762]:

block-all-mixed-content

This document (see §4.2 Opting-in)

9. Acknowledgements

In addition to the wonderful feedback gathered from the WebAppSec WG, the Chrome security team was invaluable in preparing this specification. In particular, Chris Palmer, Chris Evans, Ryan Sleevi, Michal Zalewski, Ken Buchanan, and Tom Sepez gave lots of early feedback. Anne van Kesteren explained Fetch and helped define the interface to this specification. Brian Smith helped keep the spec focused, trim, and sane.

Conformance

Document conventions

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Conformant Algorithms

Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.

Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant. Implementers are encouraged to optimize.

Index

Terms defined by this specification

Terms defined by reference

References

Normative References

[CSP3]
Mike West. Content Security Policy Level 3. 21 June 2016. WD. URL: https://www.w3.org/TR/CSP3/
[CSS-BACKGROUNDS-3]
CSS Backgrounds and Borders Module Level 3 URL: https://www.w3.org/TR/css3-background/
[FETCH]
Anne van Kesteren. Fetch Standard. Living Standard. URL: https://fetch.spec.whatwg.org/
[HTML51]
Steve Faulkner; et al. HTML 5.1. 21 June 2016. CR. URL: https://www.w3.org/TR/html51/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[RFC6455]
I. Fette; A. Melnikov. The WebSocket Protocol. December 2011. Proposed Standard. URL: https://tools.ietf.org/html/rfc6455
[RFC6797]
J. Hodges; C. Jackson; A. Barth. HTTP Strict Transport Security (HSTS). November 2012. Proposed Standard. URL: https://tools.ietf.org/html/rfc6797
[RFC7762]
M. West. Initial Assignment for the Content Security Policy Directives Registry. January 2016. Informational. URL: https://tools.ietf.org/html/rfc7762
[SECURE-CONTEXTS]
Mike West. Secure Contexts. 19 July 2016. WD. URL: https://www.w3.org/TR/secure-contexts/
[WEBSOCKETS]
Ian Hickson. The WebSocket API. 20 September 2012. CR. URL: https://www.w3.org/TR/websockets/
[URI]
T. Berners-Lee, R. Fielding and L. Masinter. Uniform Resource Identifier (URI): Generic Syntax. RFC (3986), January 2005. URL: https://tools.ietf.org/html/rfc3986.html

Informative References

[CAB]
CA/Browser Forum Baseline Requirements v1.3.7. 8 July, 2016. URL: https://cabforum.org/baseline-requirements-documents/
[RFC6919]
R. Barnes; S. Kent; E. Rescorla. Further Key Words for Use in RFCs to Indicate Requirement Levels. 1 April 2013. Experimental. URL: https://tools.ietf.org/html/rfc6919
[SRI]
Devdatta Akhawe; et al. Subresource Integrity. 23 June 2016. REC. URL: https://www.w3.org/TR/SRI/
[WSC-UI]
Thomas Roessler; Anil Saldhana. Web Security Context: User Interface Guidelines. 12 August 2010. REC. URL: https://www.w3.org/TR/wsc-ui/
[XML]
Tim Bray; et al. Extensible Markup Language (XML) 1.0 (Fifth Edition). 26 November 2008. REC. URL: https://www.w3.org/TR/xml

Issues Index

This is super hand-wavey.