Mixed Content

W3C First Public Working Draft, 22 July 2014

This version:
http://www.w3.org/TR/2014/WD-mixed-content-20140722/
Latest version:
http://www.w3.org/TR/mixed-content/
Editor’s Draft:
https://w3c.github.io/webappsec/specs/mixedcontent/
Version History:
https://github.com/w3c/webappsec/commits/master/specs/mixedcontent/index.src.html
Feedback:
public-webappsec@w3.org with subject line “[MIX] … message topic …”(archives)
Editor:
(Google Inc.)

Abstract

This specification describes how and why user agents disallow rendering and execution of content loaded 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 http://www.w3.org/TR/.

This document was published by the Web Application Security Working Group as a Working Draft. This document is intended to become a W3C Recommendation.

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 “MIX” in the subject, preferably like this: “[MIX] …summary of comment…

This document is a First Public Working Draft.

Publication as a First Public Working Draft 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.

This document was produced by the Web Application Security Working Group.

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.

Table of Contents

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

Regardless of example.com’s own privacy, users' privacy and security can be further impacted if a public resource can generate requests to private resources on a local network. For example, public resources must not be allowed to generate requests to a user’s router, or an enterprise’s internal file server.

This specification details how user agents can mitigate these risks to security and privacy by limiting a resource’s ability to inadvertently communicate in the clear, or to expose non-public resources to the web at large.

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 active content since at least version 4.

2 Key Concepts and Terminology

2.1 Terms defined by this specification

mixed content
A resource is said to be mixed content if either of the following conditions holds:
The image http://example.com/image.png is mixed content when loaded by https://not.example.com/.

The image http://127.0.0.1/image.png is mixed content when loaded by http://example.com/.

private origin
An origin is considered a private origin if any of the following conditions holds:
  • The origin’s scheme component is file.
  • The origin’s host component is localhost, or matches one of the CIDR notations 127.0.0.0/8 or ::1/128 [RFC4632]
  • The origin’s host component matches one of the private address space patterns defined in Section 3 of RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) [RFC1918].
  • The origin’s host component is an Internal Name, as defined by the CA/Browser Forum’s Baseline Requirements [CAB].
public origin
Any origin which is not private is said to be a public origin.
potentially secure origin
An origin is said to be potentially secure if one of the following is true:

Note: The mixed content checks take place after Strict Transport Security is applied to resource URLs, which simplifies determination of insecurity. [RFC6797]

a priori insecure origin
Any origin which is not potentially secure is said to be a priori insecure. We know, for example, that http://example.com/ is insecure just by looking at its scheme component.
insecure origin
An resource’s origin is said to be insecure if it is either a priori insecure, or the user agent discovers only after performing a TLS-handshake that the TLS-protection offered is either weak or deprecated.
deprecated TLS-protection
A resource’s TLS-protection is said to be deprecated if it is not weakly TLS-protected, but the user agent chooses to refuse it anyway. This determination is vendor-specific.

For example, a user agent may choose to reject resources for which the server presented a publicly-trusted certificate for an Internal Name (e.g. https://intranet/), a certificate with an overly-long validity period, a certificate signed with SHA-1, or a certificate which otherwise fails to meet the CA/Browser Forum’s Baseline Requirements.

2.2 Terms defined by reference

TLS-protected
weakly TLS-protected
These terms are defined in §5.2 of "Web Security Context: User Interface Guidelines" [WSC-UI]. A resource is TLS-protected when it is delivered over an encrypted channel. Weakly TLS-protected refers to a subset of those resources delivered over a channel that doesn’t offer strong protection of the content.

For example, resources would be considered weakly TLS-protected when delivered by a server presenting a self-signed certificate, as such a certificate only weakly authenticates the server. Similarly, a server which negotiates down to a weak cipher suite (such as TLS_RSA_WITH_NULL_MD5) would only weakly protect resources it serves.

origin
An origin defines the scope of authority or privilege under which a resource operates. It is defined in detail in the Origin specification. [RFC6454]
globally unique identifier
This term is defined in Section 4 of RFC6454. [RFC6454]

Note: URLs that do not use hierarchical elements as naming authorities (for example: blob:, and data:) have origins which are globally unique identifiers. [URI]

fetch
"fetching" is the process by which a user agent requests resources, and delivers responses. It is defined in detail in the Fetch living standard. [FETCH]
request
request client
request context
These terms are defined in Section 2.2 of the Fetch living standard. [FETCH]
response
network error
These terms are defined in detail in Section 2.3 of the Fetch living standard. [FETCH]
JavaScript global environment
This term is defined in Section 2.2.2 of the HTML5 specification. [HTML5]

3 Categories of Content

Categories of content are defined informally directly below. Note that the lists in the following three sections attempt to be comprehensive, but the platform is huge: in practice, user agents will determine a resource’s category based on it’s request context, which is much simpler to exhaustively define.

Fetch defines three request contexts that do not map directly to resources which are included in a global environment:form, navigate, and popup. These contexts are navigational request contexts, and cover navigations between pages, not content. User agents MAY treat one or more of these contexts as either active or blockable passive content if they choose to do so: there are reasonable arguments for restricting mixed form submissions, for example.

3.1 Active Content

Active content is content which can in some way directly manipulate the resource with which a user is interacting. Script and style are the clearest examples: if an attacker can manipulate either, she can completely control the activity on a webpage and exfiltrate data at will. Active content include the following resource types:

These resource types map to the following Fetch request contexts: script, worker, sharedworker, serviceworker, style, object, manifest and child. These contexts are active request contexts.

The contents of an iframe are considered active content because same-origin frames can reach up into their parent browsing context via script, and even cross-origin frames can initiate top-level navigations. User agents MAY decide to treat cross-origin frames as passive content if that capability is removed by applying a appropriate sandboxing flag set (e.g. one which does not include the allow-top-navigation flag).

Note: iframe elements, as currently implemented in user agents do come with risks beyond those mentioned above. For example, a downloaded file’s origin is often difficult to pinpoint, HTTP authentication prompts are sometimes allowed (after a HTTP 401 response, for instance), and modal prompts like window.prompt() can confuse users. These risks exist even with secure iframes, but attackers can more easily inject malicious code into innocent but insecure iframes.

Should form submissions to an insecure origin be considered active content? I suspect they should, though I’m not sure we can get away with it in a web-compatible way.

3.2 Passive Content

Passive content includes resources which cannot directly interact with or modify other resources on a page: images, fonts, audio, and video for example. The risk of rendering a manipulated passive resource is significantly lower than executing an active resource; passive content can confuse or deceive users, but cannot directly manipulate other resources on a page or exfiltrate data.

Active content is clearly dangerous in a mixed context, and must be blocked from executing in those contexts to protect both users and site authors, regardless of the risk of breaking insecurely composed websites. Passive mixed content is less directly dangerous to users: if an attacker manipulates an image resource, the worst case is that the attacker-controlled image is displayed to the user rather than the image a site’s author intended.

In a perfect world, user agents would be required to block all types of mixed content. Unfortunately, there exists a massive amount of passive mixed content on the Internet today: according to a survey in 2013 blocking passive mixed content would break around ~43% of secure websites in one way or another. Draconian blocking policies applied to passive mixed content are (for the moment) infeasible. User agents must be more nuanced in their restrictions.

With that in mind, we’ll split passive content into two categories: resources user agents can safely block without breaking the web, and resources whose usage in mixed contexts is simply too high to block by default.

Future versions of this specification will update these subcategories 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.

Should the presence of a form with an action attribute representing an a priori insecure origin be considered passive mixed content?

3.2.1 Optionally-blockable Passive Content

Passive content is optionally blockable when the risk of allowing its usage in a mixed context is outweighed by the risk of breaking significant portions of the web. This may be because usage of these resource types in mixed contexts is sufficiently high, or because the feature is very clearly low-risk in and of itself.

This category includes:

  • Images loaded via img or picture

    Note: This includes SVG documents loaded as images.

  • Video loaded via video and source elements
  • Audio loaded via audio and source elements
  • Prefetched content

These resource types map to the following Fetch request contexts: image, media, and prefetch. These contexts are optionally blockable passive request contexts.

Note: The fact that these resource types are on the "optionally blockable" list does not mean that they are safe, simply that they’re less catastrophically dangerous as the resource types on the "active" list. 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 on users.

3.2.2 Blockable Passive Content

Passive content is blockable when the risk of allowing its usage in a mixed context outweighs the risk of temporary inconvenience for those site authors delivering insecurely composed pages. This may be because usage of these features in mixed contexts is sufficiently low, or because the content is close to the boundary between active and passive.

This category includes all content that is not optionally blockable or active. For example:

Note: In particular, this category includes data loaded via XMLHttpRequest, EventSource, or WebSockets. While these communication mechanism are technically passive, developers very often use them to gather data that affects program control flow. Consider a missile silo UI that grabs JSON to determine whether to reveal the Big Red Launch Button:
{
  showLaunchButton: false
}

Or the ever-popular:

document.write("<script>" + xhr.responseText + "</script>");

These resource types map to the following Fetch request contexts: connect, download, ping, and font. These contexts are blockable passive request contexts.

3.3 Future Contexts

This document exhaustively categorizes the request contexts currently defined in the Fetch specification. It is the intention of the Working Group that any new content types defined in the future be prevented from loading as mixed content. To that end, any request context which is not explicitly listed in the preceeding content categories MUST be considered an active request context when determining whether or not a request should be blocked as mixed content.

4 User Agent Requirements

4.1 Resource Fetching

User agents SHOULD reject weakly TLS-protected resources entirely by failing the TLS handshake, or by requiring explicit user acceptance of the risk (for instance, presenting the user with a confirmation screen she must click through).

If a global environment is a secure context, then user agents MUST adhere to the following requirements when fetching resources in response to its requests (including not only requests for a Document’s subresources, but also requests made from Workers, SharedWorkers, ServiceWorkers and so on):

  1. Requests for active resources and blockable passive resources from an a priori insecure origin MUST not generate network traffic, and MUST instead return a synthetically generated network error response.
  2. Responses to requests for active resources and blockable passive resources from an insecure origin MUST not be delivered to the requesting global environment, but instead MUST return a synthetically generated network error response.
  3. Requests for optionally blockable passive resources which are mixed content SHOULD be treated as active (and therefore returned as a network error as described above).

    Note: For instance, a user agent could interpret the presence of a Strict-Transport-Security header field as forcing all content into the active category. [RFC6797]

  4. Requests for optionally blockable passive resources which are mixed content, but which are not treated as active content MAY be modified to reduce the risk to users. For example, cookies and other authentication tokens could be stripped from the requests, or the user agent could automatically change the protocol of the requested URL to HTTPS in certain cases.

If a global environment’s origin is a public origin, then user agents MUST adhere to the following requirements when fetching resources in response to the environment’s requests:

  1. Requests to private origins from public origins MUST not generate network traffic (including traffic on loopback interfaces), and MUST instead return a synthetically generated network error response.

§6 Integration with Fetch and §5 Algorithms detail how these fetching requirements could be implemented.

4.2 Script APIs

If a global environment is a secure context, then user agents MUST adhere to the following requirements when executing the following APIs:

  1. When processing XMLHttpRequest’s open() method, throw a SecurityError exception and terminate the method’s execution if the request URL provided points to an a priori insecure origin. [XMLHTTPREQUEST]
  2. When processing EventSource’s constructor, throw a SecurityError exception and terminate the constructor’s execution if the url provided points to an a priori insecure origin. [EVENTSOURCE]
  3. When processing WebSocket’s constructor, throw a SecurityError exception and terminate the constructor’s execution if the url provided points to an a priori insecure origin. [WEBSOCKETS]

4.3 UI Requirements

If a request for optionally blockable passive resources which are mixed content is not treated as active content (per requirement #3 above), then the user agent MUST NOT provide the user with a visible indication that the top-level browsing context which loaded that resource is secure (for instance, via a green lock icon). The user agent SHOULD instead display a visible indication that mixed content is present.

This requirement explicitly includes any visible indication of the top-level browsing context’s EV status. [CAB]

4.4 User Controls

User agents MAY offer users the ability to directly decide whether or not to treat all mixed content as active (meaning that even optionally blockable passive content would be blocked in a mixed context).

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

User agents MAY offer users the ability to override its decision to block blockable passive mixed content on a particular page.

User agents MAY also offer users the ability to override its decision to block active mixed content on a page.

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

5 Algorithms

5.1 Is environment a secure context?

Given a JavaScript global environment environment, the user agent determines whether environment is a secure context via the following algorithm, which returns true if environment is a secure context, and false otherwise.

  1. If environment is TLS-protected, return true.
  2. If environment is a nested browsing context, then:
    1. Let ancestorList be the list of all ancestors of environment’s browsing context.
    2. For each ancestorContext in ancestorList:
      1. Let ancestorEnvironment be the JavaScript global environment associated with ancestorContext
      2. If ancestorEnvironment is TLS-protected, return true.
  3. Return false.
If a document is a nested browsing context, user agents need 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 was not.

5.2 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 would be used as active 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. Let context be request’s context.
  2. Let client be request’s client.
  3. Let environment be the JavaScript global environment with which client is associated.
  4. Let origin be the origin of request’s URL.
  5. If origin is a private origin, and environment’s origin is a public origin, return blocked.
  6. If environment is not a secure context, return allowed.
  7. If origin is a priori insecure:
    1. If context is an active request context or blockable passive request context, return blocked.
    2. If the user agent is configured to block optionally blockable passive mixed content, return blocked.
  8. Otherwise, origin is potentially secure, so return allowed.

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 response would be used as active content, but the server is insecure). 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. Let client be request’s client.
  2. Let environment be the JavaScript global environment with which client is associated.
  3. If environment is not a secure context, return allowed.
  4. Let context be the request context of request.
  5. If context is an active request context or blockable passive request context, or the user agent is configured to block optionally blockable passive mixed content:
    1. If the response is not TLS-protected, return blocked.

      This is intended to cover cases in which a ServiceWorker responds to a request with an insecure resource. It’s not clear that this is the correct place to do that, however, as the integration with Fetch isn’t fully specified. It’s also not really clear what "insecure" should mean in a ServiceWorker context. We accept blob resources, for instance: should we accept responses synthesized by the service worker?

    2. If the response is only weakly TLS-protected, return blocked.

      Note: If a user agent is configured to reject weakly TLS-protected resources, we’ll never hit this condition, as step 6 of the Fetch algorithm would have returned a network error.

    3. If the response’s TLS-protection is deprecated, return blocked.

      Note: This covers cases in which the TLS handshake succeeds, and the resource exceeds the definition of weakly TLS-protected, but the user agent chooses to hold it to a higher standard. The definition of deprecated TLS-protection has some examples of these kinds of scenarios.

  6. Return allowed.

6 Integration with Fetch

When fetching resources, the mixed content checks described in the algorithms above should be inserted at the top of the Fetch algorithm to block network traffic to a priori insecure origins and private origins, and at the bottom of the algorithm, to block responses from insecure origins.

Fetch calls the algorithm defined in §5.2 Should fetching request be blocked as mixed content? during Step 4 of the Fetching algorithm. [FETCH]

Note: Hooking into Fetch here ensures that we catch not only the initial request, but all redirects as well. That is certainly the intent.

Further, Fetch calls the algorithm defined in §5.3 Should response to request be blocked as mixed content? during Step 7 of the Fetching algorithm. [FETCH]

Note: This hook is necessary to detect resources modified or synthesized by a ServiceWorker, as well as to determine whether a resource is insecure 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.

7 Modifications to WebSockets

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

The Establish a WebSocket Connection algorithm is modified as follows:

  1. After step 5, perform the following step:
    1. If secure is true, and the TLS handshake performed in step 5 results in a weakly TLS-protected connection, or the TLS-protection is deprecated,then the client MUST Fail the WebSocket Connection and abort the connection.

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

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.

Conformance Classes

A conformant user agent must implement all the requirements listed in this specification that are applicable to user agents.

A conformant server must implement all the requirements listed in this specification that are applicable to servers.

References

Normative References

[BEACON]
Jatinder Mann; Alois Reitbauer. Beacon. WD. URL: http://www.w3.org/TR/beacon/
[CAB]
???. CA/Browser Forum Baseline Requirements v1.1.8. URL: https://cabforum.org/baseline-requirements-documents/
[CSS21]
Bert Bos; et al. Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification. 7 June 2011. W3C Recommendation. URL: http://www.w3.org/TR/2011/REC-CSS2-20110607
[CSS3-WEBFONTS]
Michel Suignard; Chris Lilley. CSS3 module: Web Fonts. 2 August 2002. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2002/WD-css3-webfonts-20020802
[ECMA-262]
???. ECMAScript Language Specification, Third Edition. December 1999. URL: http://www.ecma-international.org/publications/standards/Ecma-262.htm
[EVENTSOURCE]
Ian Hickson. Server-Sent Events. 11 December 2012. W3C Candidate Recommendation. (Work in progress.) URL: http://www.w3.org/TR/2012/CR-eventsource-20121211/
[FETCH]
Anne van Kesteren. Fetch. Living Standard. URL: http://fetch.spec.whatwg.org/
[FILTER-EFFECTS]
Dean Jackson; Erik Dahlström; Dirk Schulze. Filter Effects 1.0. 23 May 2013. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2013/WD-filter-effects-20130523/
[HTML-IMPORTS]
Dmitri Glazkov; Hajime Morrita. HTML Imports. WD. URL: http://www.w3.org/TR/html-imports/
[HTML5]
Robin Berjon; et al. HTML5. 6 August 2013. W3C Candidate Recommendation. (Work in progress.) URL: http://www.w3.org/TR/2013/CR-html5-20130806/
[MANIFEST]
Marcos Caceres; Anssi Kostiainen; Kenneth Rohde Christiansen. Manifest for web application. WD. URL: http://w3c.github.io/manifest/
[RFC1918]
Yakov Rekhter; et al. Address Allocation for Private Internets. RFC. URL: http://www.ietf.org/rfc/rfc1918.txt
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. URL: http://www.ietf.org/rfc/rfc2119.txt
[RFC4632]
Vince Fuller; Tony Li. Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan. RFC. URL: http://www.ietf.org/rfc/rfc4632.txt
[RFC6454]
Adam Barth. The Web Origin Concept. RFC. URL: http://www.ietf.org/rfc/rfc6454.txt
[SERVICEWORKERS]
Alex Russell; Jungkee Song. Service Workers. WD. URL: http://www.w3.org/TR/service-workers/
[SVG2]
Nikos Andronikos; et al. Scalable Vector Graphics (SVG) 2. 18 June 2013. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2013/WD-SVG2-20130618/
[WEBSOCKETS]
Ian Hickson. The WebSocket API. 20 September 2012. W3C Candidate Recommendation. (Work in progress.) URL: http://www.w3.org/TR/2012/CR-websockets-20120920/
[WORKERS]
Ian Hickson. Web Workers. 1 May 2012. W3C Candidate Recommendation. (Work in progress.) URL: http://www.w3.org/TR/2012/CR-workers-20120501/
[WSC-UI]
Thomas Roessler; Anil Saldhana. Web Security Context: User Interface Guidelines. 12 August 2010. W3C Recommendation. URL: http://www.w3.org/TR/2010/REC-wsc-ui-20100812/
[XMLHTTPREQUEST]
Julian Aubourg; 송정기 (Jungkee Song); Hallvord R. M. Steen. XMLHttpRequest. 6 December 2012. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2012/WD-XMLHttpRequest-20121206/
[XSLT]
James Clark. XSL Transformations (XSLT) Version 1.0. 16 November 1999. W3C Recommendation. URL: http://www.w3.org/TR/1999/REC-xslt-19991116

Informative References

[RFC6797]
Jeff Hodges; Collin Jackson; Adam Barth. HTTP Strict Transport Security (HSTS). RFC. URL: http://www.ietf.org/rfc/rfc6797.txt
[URI]
T. Berners-Lee; R. Fielding; L. Masinter. Uniform Resource Identifiers (URI): generic syntax. January 2005. URL: http://www.ietf.org/rfc/rfc3986.txt

Index

Issues Index

Should form submissions to an insecure origin be considered active content? I suspect they should, though I’m not sure we can get away with it in a web-compatible way.
Should the presence of a form with an action attribute representing an a priori insecure origin be considered passive mixed content?
This is intended to cover cases in which a ServiceWorker responds to a request with an insecure resource. It’s not clear that this is the correct place to do that, however, as the integration with Fetch isn’t fully specified. It’s also not really clear what "insecure" should mean in a ServiceWorker context. We accept blob resources, for instance: should we accept responses synthesized by the service worker?