I ❤️ W3C : Secure Contexts

I ️ W3C : Secure Contexts

Secure Contexts

W3C Candidate Recommendation, 15 September 2016

https://www.w3.org/TR/secure-contexts/

1

1

This version:

https://www.w3.org/TR/2016/CR-secure-contexts-20160915/

Latest published version:

https://www.w3.org/TR/secure-contexts/

Editor's Draft:

https://w3c.github.io/webappsec-secure-contexts/

Previous Versions:

https://www.w3.org/TR/2016/WD-secure-contexts-20160719/

Version History:

https://github.com/w3c/webappsec-secure-contexts/commits/master/index.src.html

Feedback:

public-webappsec@w3.org with subject line “[secure-contexts] … message topic …” (archives)

Editor:

Mike West (Google Inc.)

Former Editor:

Yan Zhu (Brave)

Participate:

File an issue (open issues)

Copyright  2016 W3C (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.

---

Abstract

This specification defines "secure contexts", thereby allowing user agent implementers and specification authors to enable certain features only when certain minimum standards of authentication and confidentiality are met.

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 20 October 2016 in order to ensure the opportunity for wide review.

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

• The sandboxed secure browsing context flag defined in §2.2.1 Sandboxing, as well as its usage in §3.1 Is the environment settings object settings a secure context?. [Issue 2]
• The localhost carveout, discussed in §5.2 localhost. [Issue 6]
• The opener restriction on popups. [Issue 7]

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

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 level. As an extension of the TAG’s recommendations in[SECURING-WEB], this document describes threat models for feature abuse on the web (see §4.1 Threat Models) and outlines normative requirements which should be incorporated into documents specifying new features (see §7 Implementation Considerations).

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

Less obviously, application code delivered over an authenticated and confidential channel isn’t enough in and of itself to limit the use of powerful features by non-secure contexts. As §4.2 Ancestral Risk explains, cooperative frames can be abused to bypass otherwise solid restrictions on a feature. The algorithms defined below ensure that these bypasses are difficult and user-visible.

The following examples summarize the normative text which follows:

1.1. Top-level Documents

Top-level documents are secure as long as they don’t have a non-secure opener browsing context. This is a bit convoluted, so let’s go straight to the examples:

http://example.com/ opened in a top-level browsing context is not a secure context, as it was not delivered over an authenticated and encrypted channel.

http://example.com/

https://example.com/ opened in a top-level browsing context is a secure context, as it was delivered over an authenticated and encrypted channel.

https://example.com/

If a secure context opens https://example.com/ in a new window, that new window will be a secure context, as it is both secure on its own merits, and was opened from a secure context:https://secure.example.com/https://another.example.com/

If a non-secure context opens https://example.com/ in a new window, then things are more complicated. The new window’s status depends on how it was opened. If the non-secure context can obtain a reference to the secure context, or vice-versa, then the new window is not a secure context.

This means that the following will both produce non-secure contexts:

<a href="https://example.com/" target="_blank">Link!</a>

<script>
  var w = window.open("https://example.com/");
</script>

http://non-secure.example.com/https://another.example.com/

The link can be broken via the noopener link relation, meaning that the following will both produce secure contexts:

<a href="https://example.com/" rel="noopener" target="_blank">Link!</a>

<script>
  var w = window.open("https://example.com/", "", "noopener");
</script>

http://non-secure.example.com/https://another.example.com/

W3C’s HTML has only an extremely partial port of the noopener concept.<https://github.com/w3c/html/issues/523>

1.2. Framed Documents

Framed documents can be secure contexts if they are delivered from potentially trustworthy origins,and if they’re embedded in a secure context. That is:

If https://example.com/ opened in a top-level browsing context opens https://sub.example.com/ in a frame, then both are secure contexts, as both were delivered over authenticated and encrypted channels.https://example.com/https://sub.example.com/

If https://example.com/ was somehow able to frame http://non-secure.example.com/ (perhaps the user has overridden mixed content checking?), the top-level frame would remain secure, but the framed content is not a secure context.

https://example.com/http://non-secure.example.com/

If, on the other hand, https://example.com/ is framed inside of http://non-secure.example.com/, then it is not a secure context, as its ancestor is not delivered over an authenticated and encrypted channel.

http://non-secure.example.com/https://example.com/

1.3. Web Workers

Dedicated Workers are similar in nature to framed documents. They’re secure contexts when they’re delivered from potentially trustworthy origins, only if their owner is itself a secure context:

If https://example.com/ in a top-level browsing context runs https://example.com/worker.js, then both the document and the worker are secure contexts.

https://example.com/https://example.com/worker.js

If http://non-secure.example.com/ in a top-level browsing context frames https://example.com/, which runs https://example.com/worker.js, then neither the framed document nor the worker aresecure contexts.

http://non-secure.example.com/https://example.com/https://example.com/worker.js

1.4. Shared Workers

Multiple contexts may attach to a Shared Worker. If a secure context creates a Shared Worker, then it is a secure context, and may only be attached to by other secure contexts. If a non-secure context creates a Shared Worker, then it is not a secure context, and may only be attached to by other non-secure contexts.

If https://example.com/ in a top-level browsing context runs https://example.com/worker.js as a Shared Worker, then both the document and the worker are considered secure contexts.

https://example.com/https://example.com/worker.js

https://example.com/ in a different top-level browsing context (e.g. in a new window) is a secure context, so it may access the secure shared worker:

https://example.com/https://example.com/worker.jshttps://example.com/

https://example.com/ nested in http://non-secure.example.com/ may not connect to the secure worker, as it is not a secure context.

https://example.com/https://example.com/worker.jshttp://non-secure.example.com/https://example.com/X

Likewise, if https://example.com/ nested in http://non-secure.example.com/ runshttps://example.com/worker.js as a Shared Worker, then both the document and the worker are considered non-secure.

http://non-secure.example.com/https://example.com/https://example.com/worker.jshttps://example.com/X

1.5. Service Workers

Service Workers are always secure contexts. Only secure contexts may register them, and they may only have clients which are secure contexts.

If https://example.com/ in a top-level browsing context registers https://example.com/service.js, then both the document and the Service Worker are considered secure contexts.

https://example.com/https://example.com/service.js

2. Framework

An environment settings object is considered a secure context if the algorithm in §3.1 Is the environment settings object settings a secure context? returns "Secure", and a non-secure contextotherwise.

Likewise, a global object is considered a secure context if its relevant settings object is a secure context.

2.1. Intergration with WebIDL

This section is non-normative.

A new [SecureContext] attribute is available for operators, which ensures that they will only beexposed into secure contexts. The following example should help:

interface ExampleFeature {
  // This call will succeed in all contexts.
  Promise <double> calculateNotSoSecretResult();

  // This operation will not be exposed to a non-secure context.
  [SecureContext] Promise<double> calculateSecretResult();

  // The same applies here: the operation will not be exposed to a non-secure context.
  [SecureContext] boolean getSecretBoolean();
};

[SecureContext]
interface SecureFeature {
  // This interface will not be exposed to non-secure contexts.
  Promise<any> doAmazingThing();
};

Specification authors are encouraged to use this attribute when defining new features.

2.2. Modifications to HTML

2.2.1. Sandboxing

Developers may wish to treat sandboxed browsing contexts as secure contexts in some situations, andnon-secure contexts in others. The following sandboxing flag supports this desire:

The sandboxed secure browsing context flag

This flag asserts that content in a browsing context will be treated as a non-secure context, even if it would otherwise be considered secure.

The parse the sandboxing directive algorithm is extended by adding the following entry to the list in the final step of the algorithm which parses tokens into flags:

• The sandboxed secure browsing context flag, unless tokens contains the allow-secure-contextkeyword.

This feature is "at risk", pending the resolution of the linked issue (which itself is pending metrics gathered from browser vendors). Accordingly, no attempt has been made to upstream this to either WHATWG’s HTML or W3C’s HTML. Once we’ve decided whether or not to keep the feature, we’ll work on that. <https://github.com/w3c/webappsec-secure-contexts/issues/28>

2.2.2. Shared Workers

This section is non-normative.

The SharedWorker() constructor will throw a SecurityError exception if a secure context attempts to attach to an Worker which is not a secure context, and if a non-secure context attempts to attach to a Worker which is a secure context.

The constructor is modified as follows (though the SharedWorker specification remains the normative reference):

1. As the first substep of the SharedWorker() constructor’s current step 6.7 ("If worker global scope is not null, then run these steps:"), run the following step:

   1. If the result of executing §3.1 Is the environment settings object settings a secure context? on the current settings object does not match the result of executing the same algorithm on worker global scope’s relevant settings object, then throw a SecurityErrorexception, and abort these steps.

Note: This change landed in WHATWG’s HTML in whatwg/html#1560.

It’s not clear to me how the W3C’s [WEBWORKERS] document is updated. It looks like it’s pulling content from the WHATWG upstream, which means that the PR linked above should flow into it? But that document hasn’t been updated since 2015, so...

2.2.3. Feature Detection

To determine whether a context is capable of making use of features which require secure contexts, a simple boolean attribute is added to the global object:

partial interface WindowOrWorkerGlobalScope {
  readonly attribute boolean isSecureContext;
};

 WindowOrWorkerGlobalScope does not appear to be defined in W3C’s HTML. For the purposes of that specification, the IDL above could be interpreted as:

interface GlobalSecureContext {
  readonly attribute boolean isSecureContext;
};
Window implements GlobalSecureContext;
WorkerGlobalScope implements GlobalSecureContext;

Filed as w3c/html#522.

The isSecureContext attribute’s getter returns true if §3.1 Is the environment settings object settings a secure context? returns "Secure" when executed upon this global object’s relevant settings object, and false otherwise.

3. Algorithms

3.1. Is the environment settings object settings a secure context?

Given an environment settings object (settings) this algorithm returns "Secure" if the object represents a context which the user agent obtained via a secure channel, and "Not Secure" otherwise.

1. Let global be settings’s global object.

2. If global is a WorkerGlobalScope, then:

   1. For each Document (document) in global’s list of the worker’s Documents:

      1. Assert: Workers must be same-origin with the context that created them, so document’srelevant settings object’s origin and HTTPS state is the same as global’s relevant settings object’s origin and HTTPS state.

      2. If §3.1 Is the environment settings object settings a secure context? returns "Not Secure" when executed upon document’s relevant settings object, return "Not Secure".

   2. Return "Secure".

      Note: Given the assertion above, if we’ve reached this step, the worker must have been created from a secure context, and therefore must itself be a secure context.

3. Assert: global is a Window.

4. Let document be settings’s responsible document.

5. Return "Not Secure" if any of the following are true:

   1. document’s active sandboxing flag set contains the sandboxed secure browsing context flag.

      Note: This check is "at risk". See §2.2.1 Sandboxing for details.

   2. document has an creator browsing context (context), and context’s creator context securityis "Not Secure".

      Note: Since we take account of creator browsing contexts' status, a popups' status depends on how it is opened, as discussed in §1.1 Top-level Documents.

      The 'creator context security' concept landed in WHATWG’s HTML inwhatwg/html#1561, but doesn’t yet exist in W3C’s HTML.<https://github.com/w3c/html/issues/524>

      This exclusion is "at risk", as implementation is lagging, and there’s some discussion as to whether or not it can be softened while maintaining the mitigations against direct communication channels. <https://github.com/w3c/webappsec-secure-contexts/issues/42>

   3. settings’s HTTPS state is "deprecated".

   4. document’s active sandboxing flag set includes the sandboxed origin browsing context flag, and §3.3 Is url potentially trustworthy? returns "Not Trustworthy" when executed uponsettings’s creation URL.

      Note: We check the creation URL here because sandboxed content that is treated as being in an opaque origin (e.g. <iframe sandbox="allow-secure-context" src="http://127.0.0.1/">) would otherwise be treated as non-trustworthy by §3.2 Is origin potentially trustworthy?. Since sandboxing is a strict reduction in the content’s capabilities, and therefore in the risk it poses, we look at the origin of its URL to determine whether we would have considered it trustworthy had it not been sandboxed.

   5. document’s active sandboxing flag set does not include the sandboxed origin browsing context flag, and §3.2 Is origin potentially trustworthy? returns "Not Trustworthy" when executed upon settings’s origin.

6. Return "Secure".

3.2. Is origin potentially trustworthy?

A potentially trustworthy origin is one which a user agent can generally trust as delivering data securely.

This algorithms considers certain hosts, scheme, and origins as potentially trustworthy, even though they might not be authenticated and encrypted in the traditional sense. In particular, the user agent SHOULD treat file URLs as potentially trustworthy. In principle the user agent could treat local files as untrustworthy, but, given the information that is available to the user agent at runtime, the resources appear to have been transported securely from disk to the user agent. Additionally, treating such resources as potentially trustworthy is convenient for developers building an application before deploying it to the public.

This developer-friendlyness is not without risk, however. User agents which prioritize security over such niceties MAY choose to more strictly assign trust in a way which excludes file.

On the other hand, the user agent MAY choose to extend this trust to other, vendor-specific URL schemes like app: or chrome-extension: which it can determine a priori to be trusted (see §7.1 Packaged Applications for detail).

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

1. If origin is an opaque origin, return "Not Trustworthy".

2. Assert: origin is a tuple origin.

3. If origin’s scheme is either "https" or "wss", return "Potentially Trustworthy".

   Note: This is meant to be analog to the a priori authenticated URL concept in [MIX].

4. If origin’s host component matches one of the CIDR notations 127.0.0.0/8 or ::1/128 [RFC4632], return "Potentially Trustworthy".

5. If origin’s scheme component is file, return "Potentially Trustworthy".

6. If origin’s scheme component is one which the user agent considers to be authenticated, return "Potentially Trustworthy".

   Note: See §7.1 Packaged Applications for detail here.

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

   Note: See §7.2 Development Environments for detail here.

8. Return "Not Trustworthy".

Note: Neither origin’s domain nor port has any effect on whether or not it is considered to be asecure context.

3.3. Is url potentially trustworthy?

A potentially trustworthy URL is one which either inherits context from it’s creator (about:blank,about:srcdoc) or one whose origin is a potentially trustworthy origin. Given a URL (url), the following algorithm returns "Potentially Trustworthy" or "Not Trustworthy" as appropriate:

1. If url’s scheme is "data", return "Not Trustworthy".

   Note: This aligns the definition of a secure context with the de facto "data: URL as opaque origin" behavior that a majority of today’s browsers have agreed upon, rather than the de jure "data: URL inherits origin" behavior defined in HTML.

2. If url is "about:blank" or "about:srcdoc", return "Potentially Trustworthy".

3. Return the result of executing §3.2 Is origin potentially trustworthy? on url’s origin.

   Note: The origin of blob: and filesystem: URLs is the origin of the context in which they were created. Therefore, blobs created in a trustworthy origin will themselves be potentially trustworthy.

4. Threat models and risks

This section is non-normative.

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

4.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 mechanisms that provide for the privacy of data at the application layer, not simply integrity.

4.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 capabilities 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.2. Ancestral Risk

The §3.1 Is the environment settings object settings a secure context? algorithm walks through all the ancestors of a particular context in order to determine whether or not the context itself is secure. Why wouldn’t we consider a securely-delivered document in an iframe to be secure, in and of itself?

The short answer is that this model would enable abuse. Chrome’s implementation of [WEBCRYPTOAPI]was an early experiment in locking APIs to secure contexts, and it does not walk through a context’s ancestors. The assumption was that locking the API to a resouce which was itself delivered securely would be enough to ensure secure usage. The result, however, was that entities like Netflix built iframe- and postMessage()-based shims that exposed the API to non-secure contexts. The restriction was little more than a speed-bump, slowing down non-secure access to the API, but completely ineffective in preventing such access.

While the algorithms in this document do not perfectly isolate non-secure contexts from secure contexts (as discussed in §5.1 Incomplete Isolation), the ancestor checks provide a fairly robust protection for the guarantees of authentication, confidentiality, and integrity that such contexts ought to ptovide.

4.3. Risks associated with non-secure contexts

Certain web platform features that have a distinct impact on a user’s security or privacy should be available for use only in secure contexts in order to defend against the threats above. Features available in non-secure contexts risk exposing these capabilities to network attackers:

1. The ability to read and modify sensitive data (personally-identifying information, credentials, payment instruments, and so on). [CREDENTIAL-MANAGEMENT-1] is an example of an API that handles sensitive data.
2. The ability to read and modify input from sensors 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 of features that use sensor input.
3. The ability to access information about other devices to which a user has access.[DISCOVERY-API] and [WEB-BLUETOOTH] are good examples.
4. The ability to track users using temporary or persistent identifiers, including identifiers which reset themselves after some period of time (e.g. window.sessionStorage), identifiers the user can manually reset (e.g. [ENCRYPTED-MEDIA], Cookies [RFC6265], and [IndexedDB]), as well as identifying hardware features the user can’t easily reset.
5. The ability to introduce some state for an origin which persists across browsing sessions.[SERVICE-WORKERS] is a great example.
6. The ability to manipulate a user agent’s native UI in some way which removes, obscures, or manipulates details relevant to a user’s understanding of their context. [FULLSCREEN] is a good example.
7. The ability to introduce some functionality for which user permission will be required.

This list is non-exhaustive, but should give you a feel for the types of risks we should consider when writing or implementing specifications.

Note: While restricting a feature itself to 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.

5. Security Considerations

5.1. Incomplete Isolation

The secure context definition in this document does not completely isolate a "secure" view on an origin from a "non-secure" view on the same origin. Exfiltration will still be possible via increasingly esoteric mechanisms such as the contents of localStorage/sessionStorage, storageevents, BroadcastChannel, and others.

5.2. localhost

Section 6.3 of [RFC6761] lays out the resolution of localhost. and names falling within .localhost.as special, and suggests that local resolvers SHOULD/MAY treat them specially. For better or worse, resolvers often ignore these suggestions, and will send localhost to the network for resolution in a number of circumstances. Given that uncertainty, this document errs on the conservative side by special-casing 127.0.0.1, but not localhost.

This carveout is "at risk", as there’s currently only one implementation, and a parallel suggestion that we resolve this in the other direction, perhaps by mandating new behavior for conforming user agents' DNS resolvers to treat the SHOULDs and MAYs of the RFCs as MUSTs. <https://github.com/w3c/webappsec-secure-contexts/issues/43>

6. Privacy Considerations

The secure context definition in this document does not in itself have any privacy impact. It does, however, enable other features which do have interesting privacy implications to lock themselves into contexts which ensures that specific guarantees can be made regarding integrity, authenticity, and confidentiality.

From a privacy perspective, specification authors are encouraged to consider requiring secure contexts for the features they define.

7. Implementation Considerations

7.1. Packaged Applications

A user agent 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.

7.2. Development Environments

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

7.3. Restricting New Features

This section is non-normative.

When writing a specification for new features, we recommend that authors and editors guard sensitive APIs with checks against secure contexts. For example, something like the following might be a good approach:

1. If the current settings object is not a secure context, then:
   1. [insert something appropriate here: perhaps a Promise could be rejected with aSecurityError, an error callback could be called, a permission request denied, etc.].

Authors could alternatively ensure that sensitive APIs are only exposed to secure contexts by guarding them with the [SecureContext] attribute:

[SecureContext]
interface SensitiveFeature {
  Promise<double> getTheSecretDouble();
};

// Or:

interface AnotherSensitiveFeature {
  [SecureContext] void doThatPowerfulThing();
};

7.4. Restricting Legacy Features

This section is non-normative.

The list above clearly includes some existing functionality that is currently available to the web over non-secure channels. We recommend that such legacy functionality be modified to begin requiring a secure context as quickly as is reasonably possible [W3C-PROCESS].

1. If such a feature is not widely implemented, we recommend that the specification be immediatelymodified to include a restriction to secure contexts.

2. If such a feature is widely implemented, but not yet in wide use, we recommend that it be quickly restricted to secure contexts by adding a check as described in §7.3 Restricting New Features to existing implementations, and modifying the specification accordingly.

3. If such a feature is in wide use, we recommend that the existing functionality be deprecated; the specification should be modified to note that it does not conform to the restrictions outlined in this document, and a plan should be developed to both offer a conformant version of the feature and to migrate existing users into that new version.

7.4.1. Example: Geolocation

The [GEOLOCATION-API] is a good concrete example of such a feature; it is widely implemented and used on a large number of non-secure sites. A reasonable path forward might look like this:

1. Modify the specification to include checks against secure context before executing the algorithms for getCurrentPosition() and watchPosition().

   If the current settings object is not a secure context, then the algorithm should be aborted, and the errorCallback invoked with a code of PERMISSION_DENIED.

2. The user agent should announce clear intentions to disable the API for non-secure contexts on a specific date, and warn developers accordingly (via console messages, for example).

3. Leading up to the flag day, the user agent should announce a deprecation schedule to ensure both that site authors recognize the need to modify their code before it simply stops working altogether, and to protect users in the meantime. Such a plan might include any or all of:

   1. Disallowing persistent permission grants to non-secure origins

   2. Coarsening the accuracy of the API for non-secure origins (perhaps consistently returning city-level data rather than high-accuracy data)

      1. UI modifications to inform users and site authors of the risk

8. 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, Jonathan Watt, Boris Zbarsky, 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 withclass="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

• allow-secure-context, in §2.2.1
• isSecureContext, in §2.2.3
• non-secure context, in §2
• potentially trustworthy origin, in §3.2
• potentially trustworthy URL, in §3.3
• sandboxed secure browsing context flag, in §2.2.1
• secure context, in §2

Terms defined by reference

• [GEOLOCATION-API] defines the following terms:
  • getCurrentPosition()
  • watchPosition()
• [HTML] defines the following terms:
  • WindowOrWorkerGlobalScope
  • creator context security
  • noopener
• [html51] defines the following terms:
  • Document
  • Window
  • active sandboxing flag set
  • browsing context
  • concept origin
  • creation url
  • creator browsing context
  • current settings object
  • domain
  • environment settings object
  • global object
  • host
  • https state
  • iframe
  • opaque origin
  • opener browsing context
  • origin
  • parse the sandboxing directive
  • port
  • relevant settings object
  • responsible document
  • sandboxed origin browsing context flag
  • scheme
  • the environment settings object's global object
  • top-level browsing context
  • tuple origin
• [MIX] defines the following terms:
  • a priori authenticated url
• [W3C-PROCESS] defines the following terms:
  • modify a specification
• [WebIDL-2] defines the following terms:
  • [securecontext]
  • exposed
• [WEBWORKERS] defines the following terms:
  • SharedWorker()
  • WorkerGlobalScope
  • the worker's documents
• [URL] defines the following terms:
  • URL
  • origin
  • scheme

References

Normative References

[HTML]

Ian Hickson. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/

[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

[RFC4632]

V. Fuller; T. Li. Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan. August 2006. Best Current Practice. URL: https://tools.ietf.org/html/rfc4632

[W3C-PROCESS]

Charles McCathie Nevile. World Wide Web Consortium Process Document. URL:https://www.w3.org/20145/Process-20150901/

[WEBWORKERS]

Ian Hickson. Web Workers. 24 September 2015. WD. URL: https://www.w3.org/TR/workers/

[URL]

Anne van Kesteren. URL Standard. Living Standard. URL: https://url.spec.whatwg.org/
Note: URLs can be used in numerous different manners, in many differing contexts. For the purpose of producing strict URLs one may wish to consider [RFC3986] [RFC3987].

Informative References

[COMCAST]

David Kravets. Comcast Wi-Fi serving self-promotional ads via JavaScript injection. URL:https://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/

[CREDENTIAL-MANAGEMENT-1]

Mike West. Credential Management Level 1. 25 April 2016. WD. URL:https://www.w3.org/TR/credential-management-1/

[DISCOVERY-API]

Rich Tibbett. Network Service Discovery. 20 February 2014. WD. URL:https://www.w3.org/TR/discovery-api/

[ENCRYPTED-MEDIA]

David Dorwin; et al. Encrypted Media Extensions. 5 July 2016. CR. URL:https://www.w3.org/TR/encrypted-media/

[FULLSCREEN]

Anne van Kesteren. Fullscreen API Standard. Living Standard. URL:https://fullscreen.spec.whatwg.org/

[GEOLOCATION-API]

Andrei Popescu. Geolocation API Specification. 28 May 2015. PER. URL:https://www.w3.org/TR/geolocation-API/

[IndexedDB]

Nikunj Mehta; et al. Indexed Database API. 8 January 2015. REC. URL:https://www.w3.org/TR/IndexedDB/

[MEDIACAPTURE-STREAMS]

Daniel Burnett; et al. Media Capture and Streams. 19 May 2016. CR. URL:https://www.w3.org/TR/mediacapture-streams/

[MIX]

Mike West. Mixed Content. 2 August 2016. CR. URL: https://www.w3.org/TR/mixed-content/

[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

[RFC6265]

A. Barth. HTTP State Management Mechanism. April 2011. Proposed Standard. URL:https://tools.ietf.org/html/rfc6265

[RFC6761]

S. Cheshire; M. Krochmal. Special-Use Domain Names. February 2013. Proposed Standard. URL:https://tools.ietf.org/html/rfc6761

[RFC7258]

S. Farrell; H. Tschofenig. Pervasive Monitoring Is an Attack. May 2014. Best Current Practice. URL: https://tools.ietf.org/html/rfc7258

[SECURING-WEB]

Mark Nottingham. Securing the Web. Finding. URL: https://www.w3.org/2001/tag/doc/web-https

[SERVICE-WORKERS]

Alex Russell; Jungkee Song; Jake Archibald. Service Workers. 25 June 2015. WD. URL:https://www.w3.org/TR/service-workers/

[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/

[WEB-BLUETOOTH]

Jeffrey Yasskin. Web Bluetooth. Draft Community Group Report. URL:https://webbluetoothcg.github.io/web-bluetooth/

[WEBCRYPTOAPI]

Ryan Sleevi; Mark Watson. Web Cryptography API. 11 December 2014. CR. URL:https://www.w3.org/TR/WebCryptoAPI/

[WebIDL-2]

Cameron McCormack; Boris Zbarsky. Web IDL (Second Edition). 23 June 2016. ED. URL:https://heycam.github.io/webidl/

IDL Index

partial interface WindowOrWorkerGlobalScope {
  readonly attribute boolean isSecureContext;
};

Issues Index

 W3C’s HTML has only an extremely partial port of the noopener concept.<https://github.com/w3c/html/issues/523>↵

 This feature is "at risk", pending the resolution of the linked issue (which itself is pending metrics gathered from browser vendors). Accordingly, no attempt has been made to upstream this to either WHATWG’s HTML or W3C’s HTML. Once we’ve decided whether or not to keep the feature, we’ll work on that. <https://github.com/w3c/webappsec-secure-contexts/issues/28>↵

 It’s not clear to me how the W3C’s [WEBWORKERS] document is updated. It looks like it’s pulling content from the WHATWG upstream, which means that the PR linked above should flow into it? But that document hasn’t been updated since 2015, so...↵

 WindowOrWorkerGlobalScope does not appear to be defined in W3C’s HTML. For the purposes of that specification, the IDL above could be interpreted as:

interface GlobalSecureContext {
  readonly attribute boolean isSecureContext;
};
Window implements GlobalSecureContext;
WorkerGlobalScope implements GlobalSecureContext;

Filed as w3c/html#522.

↵

 The 'creator context security' concept landed in WHATWG’s HTML in whatwg/html#1561, but doesn’t yet exist in W3C’s HTML. <https://github.com/w3c/html/issues/524>↵

 This exclusion is "at risk", as implementation is lagging, and there’s some discussion as to whether or not it can be softened while maintaining the mitigations against direct communication channels. <https://github.com/w3c/webappsec-secure-contexts/issues/42>↵

 This carveout is "at risk", as there’s currently only one implementation, and a parallel suggestion that we resolve this in the other direction, perhaps by mandating new behavior for conforming user agents' DNS resolvers to treat the SHOULDs and MAYs of the RFCs as MUSTs. <https://github.com/w3c/webappsec-secure-contexts/issues/43>↵

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1