Requirements for Powerful Features

W3C First Public Working Draft, 4 December 2014

This version:
http://www.w3.org/TR/2014/WD-POWER-1-20141204/
Latest version:
http://www.w3c.org/TR/powerful-features/
Editor's Draft:
https://w3c.github.io/webappsec/specs/powerfulfeatures/
Version History:
https://github.com/w3c/webappsec/commits/master/specs/powerfulfeatures/index.src.html
Feedback:
public-webappsec@w3.org with subject line “[POWER] … message topic …” (archives)
Editor:
(Google Inc.)

Abstract

This specification provides guidelines for user agent implementors and spec authors for implementing features whose properties dictate that they only be exposed to the web within a trustworthy environment.

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 “POWER” in the subject, preferably like this: “[POWER] …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.

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

Table of Contents

1. Introduction

This section is not normative.

As the Web platform is extended to enable more useful and powerful applications, it becomes increasingly important to ensure that the features which enable those applications are enabled only in contexts which meet a minimum security bar. This document outlines threat models for feature abuse on the Web and outline normative requirements which should be incorporated into documents specifying new features.

The most obvious of the requirements discussed here is that application code with access to sensitive or private data be delivered over authenticated and confidential channels that guarantee data integrity. Delivering code securely cannot ensure that an application will always meet a user’s security and privacy requirments, but it is a necessary precondition.

2. Key Concepts and Terminology

2.1. Terms defined by this specification

powerful feature
Defined in §3 Is [insert feature here] powerful? .
sufficiently secure context
A Document is considered sufficiently secure if the algorithm defined in §4.1 Is Document a sufficiently secure context? returns Sufficiently Secure when executed upon it.

Likewise, a settings object is considered sufficiently secure if the algorithm defined in §4.2 Is settings object a sufficiently secure context? returns Sufficiently Secure when executed upon it.

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

2.2. Terms defined by reference

An origin defines the scope of authority or privilege under which a resource operates. It boils down to a tuple of scheme, host, and port. The concept is defined in detail in [RFC6454].

A potentially secure origin is an origin that isn’t insecure a priori, defined in detail in [MIX].

The TLS State of a Response is defined in [FETCH].

The following terms are defined in [HTML5]:

3. Is [insert feature here] powerful?

Certain web platform features that have a distinct impact on a user’s security or privacy should be available for use only in sufficiently secure contexts.

Broadly speaking, we consider a feature powerful enough to restrict when it fits into one or more of the following categories:

  1. The feature provides access to sensitive data (personally-identifying information, credentials, payment instruments, and so on). [CREDENTIAL-MANAGEMENT] is an example of such an API.
  2. The feature provides access to sensor data on a user’s device (camera, microphone, and GPS being particularly noteworthy, but certainly including less obviously dangerous sensors like the accelerometer). [GEOLOCATION-API] and [MEDIACAPTURE-STREAMS] are historical examples.
  3. The feature provides access to or information about other devices a user has access to. [DISCOVERY] and [BLUETOOTH] are good examples.
  4. The feature exposes temporary or persistent identifiers, including identifying hardware features the user can’t easily reset. [ENCRYPTED-MEDIA] for instance.
  5. The feature introduces some state for an origin which persists across browsing sessions. [SERVICE-WORKERS] is a great example.
  6. The feature introduces some functionality for which user permission will be required.

This list is non-exhaustive, but should give you a feel for the types of features you should be concerned about.

We need to distinguish between legacy features like cookies, localStorage, IndexedDB, etc, which all persist state (and potentially identifiers) across browsing sessions. They’re certainly not features we can reasonably limit to secure contexts in the forseeable future. This might involve language along the lines of what mnot@ proposed in "Adapting Existing Specifications".

Note: While restricting the feature itself to sufficiently secure contexts is critical, we ought not forget that facilities that carry such information (such as new network access mechanisms, or other generic functions with access to network data) are equally sensitive.

3.1. Threat Models

Granting permissions to unauthenticated origins is, in the presence of a network attacker, equivalent to granting the permissions to any origin. The state of the Internet is such that we must indeed assume that a network attacker is present. Generally, network attackers fall into 2 classes: passive and active.

3.1.1. Passive Network Attacker

A "Passive Network Attacker" is a party who is able to observe traffic flows but who lacks the ability or chooses not to modify traffic at the layers which this specification is concerned with.

Surveillance of networks in this manner "subverts the intent of communicating parties without the agreement of these parties" and one "cannot defend against the most nefarious actors while allowing monitoring by other actors no matter how benevolent some might consider them to be." [RFC7258] Therefore, the algorithms defined in this document require mechansims that provide for the privacy of data at the application layer, not simply integrity.

3.1.2. Active Network Attacker

An "Active Network Attacker" has all the capabilities of a "Passive Network Attacker" and is additionally able to modify, block or replay any data transiting the network. These capabilties are available to potential adversaries at many levels of capability, from compromised devices offering or simply participating in public wireless networks, to Internet Service Providers indirectly introducing security and privacy vulnerabilities while manipulating traffic for financial gain ([VERIZON] and [COMCAST] are recent examples), to parties with direct intent to compromise security or privacy who are able to target individual users, organizations or even entire populations.

4. Algorithms

4.1. Is Document a sufficiently secure context?

Given a Document document, this algorithm returns Sufficiently Secure if the Document represents a sufficiently secure context or Insecure otherwise.

  1. While document corresponds to an iframe srcdoc Document, let document be that Document’s browsing context’s browsing context container’s Document.
  2. Let origin be the origin of 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.
  4. Let result be the result of executing the §4.2 Is settings object a sufficiently secure context? algorithm on document’s incumbent settings object.
  5. If result is Insecure, return Insecure.
  6. Otherwise:
    1. If document has an embedding document, return the result of executing §4.1 Is Document a sufficiently secure context? on document’s embedding document with the ancestors flag set to true.
    2. Otherwise, return result.

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 allow powerful features.

Need to consider how contexts created from blob: and data: are treated here, e.g. when used to create a Worker or SharedWorker.

4.2. Is settings object a sufficiently secure context?

Given an settings object settings, this algorithm returns Sufficiently Secure if the object represents a sufficiently secure context, and Insecure otherwise.

  1. If settings' TLS state is authenticated, return Sufficiently Secure.
  2. Otherwise:
    1. Let origin be settings' origin.
    2. If the result of executing the §4.3 Is origin potentially trustworthy? algorithm on origin is Potentially Trustworthy, return Sufficiently Secure.
  3. Return Insecure.

4.3. Is origin potentially trustworthy?

Certain origins are always potentially trustworthy. In particular, UAs MUST treat file URLs and URLs with hostnames names equivalent to "localhost" as potentially trustworthy. In principle the UA could treat local files and local web servers as untrustworthy. However, given the information that is available to the UA at runtime, the resources appear to have been transported securely. Additionally, treating such resources as potentially trustworthy is convenient for developers building an application before deploying it to the public.

A user agent MAY choose to extend this trust to other, vendor-specific URL schemes like app: or chrome-extension:.

Given an origin origin, the following algorithm returns Potentially Trustworthy or Not Trustworthy as appropriate.

  1. If origin is a potentially secure origin, return Potentially Trustworthy.

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

  2. If origin’s host component is or falls within localhost. [RFC6761], return Potentially Trustworthy.
  3. If origin’s host component matches one of the CIDR notations 127.0.0.0/8 or ::1/128 [RFC4632], return Potentially Trustworthy.
  4. If origin’s scheme component is file, return Potentially Trustworthy.
  5. If origin’s scheme component is one which the user agent considers to be authenticated, return Potentially Trustworthy.

    Note: See §5.1 Packaged Applications for detail here.

  6. If origin has been configured as a trustworthy origin, return Potentially Trustworthy.

    Note: See §5.2 Development Environments for detail here.

  7. Return Not Trusted.

5. Implementation Considerations

5.1. Packaged Applications

User agents that support packaged applications MAY whitelist specific URL schemes whose contents are authenticated by the user agent. For example, FirefoxOS application resources are referred to by a URL whose scheme component is app:. Likewise, Chrome’s extensions and apps live on chrome-extension: schemes. These could reasonably be considered trusted origins.

5.2. Development Environments

In order to support developers who run staging servers on non-loopback hosts, user agents MAY allow users to configure specific sets of origins as trustworthy, even though §4.3 Is origin potentially trustworthy? would normally return Not Trusted.

6. Acknowledgements

This document is largely based on the Chrome Security team’s work on [POWERFUL-NEW-FEATURES]. Chris Palmer, Ryan Sleevi, and David Dorwin have been particularly engaged. Anne van Kesteren and Henri Sivonen have also provided very helpful feedback.

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

[FETCH]
Anne van Kesteren. Fetch. Living Standard. URL: https://fetch.spec.whatwg.org/
[MIX]
Mike West. Mixed Content. ED. URL: https://w3c.github.io/webappsec/specs/mixedcontent/
[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
[RFC6761]
Stuart Cheshire; Marc Krochmal. Special-Use Domain Names. RFC. URL: http://www.ietf.org/rfc/rfc6761.txt
[html5]
Robin Berjon; et al. HTML5. 28 October 2014. REC. URL: http://www.w3.org/TR/html5/
[rfc2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: http://www.ietf.org/rfc/rfc2119.txt

Informative References

[BLUETOOTH]
Jeffrey Yasskin; Vincent Scheib. Web Bluetooth. URL: https://webbluetoothcg.github.io/web-bluetooth/
[COMCAST]
David Kravets. Comcast Wi-Fi serving self-promotional ads via JavaScript injection. URL: http://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/
[CREDENTIAL-MANAGEMENT]
Mike West. Credential Management. ED. URL: https://w3c.github.io/webappsec/specs/credentialmanagement/
[DISCOVERY]
Rich Tibbett. Network Service Discovery. URL: https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html
[POWERFUL-NEW-FEATURES]
Chrome Security Team. Prefer Secure Origins For Powerful New Features. URL: https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features
[RFC7258]
Stephen Farrell; Hannes Tschofenig. Pervasive Monitoring Is an Attack. RFC. URL: http://www.ietf.org/rfc/rfc7258.txt
[VERIZON]
Mark Bergen; Alex Kantrowitz. Verizon looks to target its mobile subscribers with ads. URL: http://adage.com/article/digital/verizon-target-mobile-subscribers-ads/293356/
[encrypted-media]
David Dorwin; et al. Encrypted Media Extensions. 28 August 2014. WD. URL: http://www.w3.org/TR/encrypted-media/
[geolocation-API]
Andrei Popescu. Geolocation API Specification. 24 October 2013. REC. URL: http://www.w3.org/TR/geolocation-API/
[mediacapture-streams]
Daniel Burnett; et al. Media Capture and Streams. 3 September 2013. WD. URL: http://www.w3.org/TR/mediacapture-streams/
[service-workers]
Alex Russell; Jungkee Song. Service Workers. 8 May 2014. WD. URL: http://www.w3.org/TR/service-workers/

Index

Issues Index

We need to distinguish between legacy features like cookies, localStorage, IndexedDB, etc, which all persist state (and potentially identifiers) across browsing sessions. They’re certainly not features we can reasonably limit to secure contexts in the forseeable future. This might involve language along the lines of what mnot@ proposed in "Adapting Existing Specifications".
Need to consider how contexts created from blob: and data: are treated here, e.g. when used to create a Worker or SharedWorker.