Mixed Content

Editor’s Draft, 14 September 2014

This version:
https://w3c.github.io/webappsec/specs/mixedcontent/
Latest version:
http://www.w3c.org/TR/mixed-content/
Previous Versions:
http://www.w3.org/TR/2014/WD-mixed-content-20140722/
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 user agents should handle 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 is a public copy of the editors’ draft. It is provided for discussion only and may change at any moment. Its publication here does not imply endorsement of its contents by W3C. Don’t cite this document other than as work in progress.

Changes to this document may be tracked at https://github.com/w3c/webappsec.

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

This document is governed by the 1 August 2014 W3C Process Document.

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 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
private URL
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].

A URL whose origin is private is itself considered to be private.

public origin
public URL
Any origin which is not private is said to be a public origin.

A URL whose origin is public is itself considered to be public.

potentially secure origin
potentially secure URL
An origin is said to be potentially secure if one of the following is true:

A URL whose origin is potentially secure is itself considered to be potentially secure.

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
a priori insecure URL
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.

A URL whose origin is a priori insecure is itself considered to be a priori insecure.

insecure origin
insecure URL
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.

A URL whose origin is insecure is itself considered to be insecure.

unsecured environment
A JavaScript global environment is called unsecured if it does not restrict mixed content.
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. [CAB]

Note: We recommend that user agents return network errors rather than fetching resources whose TLS-protection is deprecated.

authenticated origin
authenticated environment
An origin can be called authenticated when it either refers to a source which is impossible not to trust (e.g. localhost), or to a source which can be adequately verified as authentic.

A JavaScript global environment can be called authenticated if its origin is authenticated.

These are spelled out in more detail in the §5.4 Is origin an authenticated origin? and §5.5 Is environment an authenticated environment? algorithms.

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 which does not chain to a root certificate in the user agent’s local trust store, 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.

Note: We recommend that user agents return network errors rather than fetching resources whose TLS-protection is weak.

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
request context frame type
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]
document environment
worker environment
These terms are defined in Section 6.1.3.1 of the HTML5 specification. [[!!HTML5]]

3 Content Categories

In a perfect world, user agents would be required to block all mixed content without exception. Unfortunately, that is impractical on today’s internet. For instance, a survey in 2013 notes that blocking mixed content would break around ~43% of secure websites in one way or another [DANGEROUS-MIX]. Draconian blocking policies applied to some types of mixed content are (for the moment) infeasible. User agents need to be more nuanced in their restrictions.

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

Future versions of this specification will update these categories 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 is considered optionally-blockable content 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, or because the resource is very clearly low-risk in and of itself. This category of content includes:

These resource types map to the following Fetch request contexts: audio, image, prefetch, and video. These contexts are optionally-blockable request contexts.

Note: 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 on users.

Note: 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 that mixed content images loaded via <img crossorigin ...> will be blocked. This is a good example of the general principle that a category of content falls into this category only when it is too widely used to be blocked outright. The working group intends to find more blockable subsets of an otherwise optionally-blockable request context.

3.2 Blockable Content

Any resource that isn’t optionally-blockable is considered blockable content. A non-exhaustive sample of content that falls into this category includes:

These resource types map to the following Fetch request contexts: beacon, cspreport, download, embed, eventsource, favicon, fetch, font, form, frame, hyperlink, iframe, imageset, location, manifest, object, ping, plugin, script, serviceworker, sharedworker, subresource, style, track, worker, xmlhttprequest, and xslt. These contexts are the blockable request contexts.

Note: The request contexts form, hyperlink, and location might refer to top-level browsing context navigations, which are not considered mixed content. See the treatment of request context frame type in §5.2 Should fetching request be blocked as mixed content? for details.

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 a blockable request context.

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 restricts mixed content, 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 blockable 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 blockable 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 resources which are mixed content SHOULD be treated as blockable (and therefore returned as a network error as described above), but user agents MAY allow them to load normally.

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

  4. Requests for optionally-blockable resources which are mixed 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 restricts mixed content, 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 Form Submission

If a global environment restricts mixed content, then user agents MAY optionally choose to warn users of the presence of one or more form elements with action attributes whose values are insecure 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, user agents MAY optionally treat form submissions in the top-level browsing context from a global environment which restricts mixed content as a request for blockable content to protect users from accidental data leakage.

4.4 UI Requirements

If a request for an optionally-blockable resource which is mixed content is not treated as blockable, 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.5 User Controls

User agents MAY offer users the ability to directly decide whether or not to treat all mixed content as blockable (meaning that even optionally-blockable 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 mixed content on a particular page.

Note: Practically, user agents 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 user agents REALLY SHOULD NOT present such a choice to users without careful consideration and communication of the risk involved.

5 Algorithms

5.1 Does environment restrict mixed content?

Given a JavaScript global environment environment, the user agent determines whether environment restricts mixed content via the following algorithm, which returns true if environment restricts mixed content, and false otherwise.

  1. If environment is TLS-protected, and that TLS-protection is neither weak nor deprecated, then 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, and that TLS-protection is neither weak nor deprecated, then 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 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. Let context be request’s context.
  2. Let frame type be request’s context frame type.
  3. Let client be request’s client.
  4. Let environment be the JavaScript global environment with which client is associated.
  5. Let origin be the origin of request’s URL.
  6. If origin is a private origin, and environment’s origin is a public origin, return blocked.
  7. If environment does not restrict mixed content, return allowed.
  8. If request’s context frame type is top-level, return allowed.
  9. If origin is a priori insecure:
    1. If request’s mode is CORS or CORS-with-forced-preflight, return blocked.
    2. If context is a blockable request context, return blocked.
    3. If the user agent is configured to block optionally-blockable mixed content, return blocked.
  10. 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 is for blockable 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 does not restrict mixed content, return allowed.
  4. Let context be the request context of request.
  5. If context is an blockable request context or the user agent is configured to block optionally-blockable 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. [FETCH]

    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.

5.4 Is origin an authenticated origin?

Given an origin origin, this algorithm returns authenticated if the origin is an authenticated origin, and unauthenticated otherwise.

  1. If origin is not an insecure origin, return authenticated.
  2. If origin’s host component is localhost, return authenticated.
  3. If origin’s host component matches one of the CIDR notations 127.0.0.0/8 or ::1/128 [RFC4632], return authenticated.
  4. If origin’s scheme component is file, return authenticated.
  5. If origin’s scheme component is one which the user agent considers to be authenticated, return authenticated.
  6. Return unauthenticated.

Note: The origin of blob: and filesystem: URLs is the origin of the context in which they were created. Therefore, blobs created in an authenticated origin will themselves be authenticated. The origin of data: and javascript: URLs is an opaque identifier, which will not be considered authenticated.

Note: Step #5 above is meant to cover vendor-specific URL schemes whose contents are authenticated by the user agent. For example, FirefoxOS application resources are referred to with an URL whose scheme component is app:. Likewise, Chrome’s extensions and apps live on chrome-extension: schemes. These could reasonably be considered authenticated origins.

5.5 Is environment an authenticated environment?

Given a JavaScript global environment environment, this algorithm returns authenticated if the environment is an authenticated environment, and unauthenticated otherwise.

  1. Let origin be the origin specified by environment’s entry settings object.
  2. If environment is a document environment:
    1. Let document be the Document object of the active document of the browsing context of environment’s global object.
    2. While document corresponds to an iframe srcdoc Document, let document be that Document’s browsing context’s browsing context container’s Document.
    3. If document’s active sandboxing flag set has its sandboxed origin browsing context flag set:
      1. Set origin to the origin of document’s address.
  3. Return the result of executing the §5.4 Is origin an authenticated origin? algorithm on origin.

Note: Sandboxed documents will have a unique origin. This algorithm uses the location of a sandboxed document to determine whether it should be considered authenticated. That is, the document inside <iframe src="https://example.com/" sandbox="allow-script"> would be considered to have an authenticated environment.

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 [RFC6455] is modified as follows:

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

[CAB]
???. CA/Browser Forum Baseline Requirements v1.1.8. URL: https://cabforum.org/baseline-requirements-documents/
[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/
[HTML5]
Robin Berjon; et al. HTML5. 17 June 2014. W3C Candidate Recommendation. (Work in progress.) URL: http://www.w3.org/TR/2014/WD-html5-20140617/
[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
[RFC6455]
Ian Fette; Alexey Melnikov. The WebSocket Protocol. RFC. URL: http://www.ietf.org/rfc/rfc6455.txt
[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/
[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/

Informative References

[BEACON]
Jatinder Mann; Alois Reitbauer. Beacon. WD. URL: http://www.w3.org/TR/beacon/
[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
[DANGEROUS-MIX]
Ping Chen; et al. A Dangerous Mix: Large-scale analysis of mixed-content websites. URL: http://www.securitee.org/files/mixedinc_isc2013.pdf
[ECMA-262]
???. ECMAScript Language Specification, Third Edition. December 1999. URL: http://www.ecma-international.org/publications/standards/Ecma-262.htm
[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]
Ian Hickson. HTML. Living Standard. URL: http://www.whatwg.org/specs/web-apps/current-work/multipage/
[HTML-IMPORTS]
Dmitri Glazkov; Hajime Morrita. HTML Imports. WD. URL: http://www.w3.org/TR/html-imports/
[MANIFEST]
Marcos Caceres; Anssi Kostiainen; Kenneth Rohde Christiansen; et al. Manifest for web application. WD. URL: http://w3c.github.io/manifest/
[RFC6797]
Jeff Hodges; Collin Jackson; Adam Barth. HTTP Strict Transport Security (HSTS). RFC. URL: http://www.ietf.org/rfc/rfc6797.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/
[URI]
T. Berners-Lee; R. Fielding; L. Masinter. Uniform Resource Identifiers (URI): generic syntax. January 2005. URL: http://www.ietf.org/rfc/rfc3986.txt
[WORKERS]
Ian Hickson. Web Workers. 1 May 2012. W3C Candidate Recommendation. (Work in progress.) URL: http://www.w3.org/TR/2012/CR-workers-20120501/
[XSLT]
James Clark. XSL Transformations (XSLT) Version 1.0. 16 November 1999. W3C Recommendation. URL: http://www.w3.org/TR/1999/REC-xslt-19991116

Index

Issues Index

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?