From b9df88cf6050f52164a25ea6d0cb92af04317236 Mon Sep 17 00:00:00 2001 From: Dominique Hazael-Massieux Date: Fri, 10 Nov 2023 09:59:50 +0000 Subject: [PATCH] Update a few references and simplify some bikeshed-isms (#101) SHA: 88c94452a8c429fab23557583b150499a88d100c Reason: push, by mikewest Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> --- index.html | 1433 +++++++++++++++++++++++++++++++--------------------- 1 file changed, 868 insertions(+), 565 deletions(-) diff --git a/index.html b/index.html index dcbcaa8..89b265f 100644 --- a/index.html +++ b/index.html @@ -3,10 +3,11 @@ Secure Contexts - - + + + - + - - + - + - + - + + - + - + -
-

+

Secure Contexts

-

Editor’s Draft,

-
- Specification Metadata +

Editor’s Draft,

+
+ More details about this document
This version: @@ -608,10 +689,9 @@

https://github.com/w3c/webappsec-secure-contexts/commits/main/index.bs
Feedback:
public-webappsec@w3.org with subject line “[secure-contexts] … message topic …” (archives) +
GitHub
Implementation Report:
https://wpt.fyi/results/secure-contexts -
Issue Tracking: -
GitHub
Editor:
(Google Inc.)
Former Editor: @@ -622,7 +702,7 @@

-

Copyright © 2021 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.

+

Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.

@@ -632,7 +712,7 @@

Status of this 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. @@ -645,13 +725,13 @@

@@ -717,12 +797,6 @@

Table of Contents

  • 8 Acknowledgements -
  • - Conformance -
      -
    1. Document conventions -
    2. Conformant Algorithms -
  • Index
      @@ -744,7 +818,7 @@

      1. 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], + 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 @@ -761,7 +835,7 @@

      1. 1.1. Top-level Documents

      -

      http://example.com/ opened in a top-level browsing +

      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.

      @@ -773,7 +847,7 @@

      -

      https://example.com/ opened in a top-level browsing +

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

      @@ -824,7 +898,7 @@

      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 + 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. @@ -878,7 +952,7 @@

      -

      If https://example.com/ in a top-level browsing +

      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.

      @@ -897,7 +971,7 @@

      -

      If http://non-secure.example.com/ in a top-level browsing +

      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 are secure contexts.

      @@ -925,7 +999,7 @@

      -

      If https://example.com/ in a top-level browsing +

      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.

      @@ -945,7 +1019,7 @@

      -

      https://example.com/ in a different top-level +

      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:

      @@ -1034,7 +1108,7 @@

      .

      -

      If https://example.com/ in a top-level browsing +

      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.

      @@ -1057,8 +1131,8 @@

      2. Framework

      This section is non-normative.

      2.1. Integration with WebIDL

      -

      A new [SecureContext] attribute is available for operators, which - ensures that they will only be exposed into secure contexts. The +

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

      @@ -1067,13 +1141,13 @@

      SecureContext] Promise<double> calculateSecretResult(); + [SecureContext] Promise<double> calculateSecretResult(); // The same applies here: the operation will not be exposed to a non-secure context. - [SecureContext] boolean getSecretBoolean(); + [SecureContext] boolean getSecretBoolean(); }; -[SecureContext] +[SecureContext] interface SecureFeature { // This interface will not be exposed to non-secure contexts. Promise<any> doAmazingThing(); @@ -1084,15 +1158,15 @@

      2.2. Integrations with HTML

      2.2.1. Shared Workers

      -

      The SharedWorker constructor will throw a "SecurityError" DOMException exception if a secure context attempts to attach to +

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

      2.2.2. Feature Detection

      An application can determine whether it’s executing in a secure context by checking the isSecureContext boolean defined on WindowOrWorkerGlobalScope.

      2.2.3. Secure and non-secure contexts

      -

      The HTML Standard defines whether an environment is a secure context or a non-secure context. This is the primary mechanism used by other +

      The HTML Standard defines whether an environment is a secure context or a non-secure context. This is the primary mechanism used by other specifications.

      -

      Given a global object, specifications can check whether its relevant settings object (which is an environment) is a secure context.

      +

      Given a global object, specifications can check whether its relevant settings object (which is an environment) is a secure context.

      3. Algorithms

      @@ -1114,57 +1188,57 @@

      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 +

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

        +

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

      2. -

        Assert: origin is a tuple origin.

        +

        Assert: origin is a tuple origin.

      3. -

        If origin’s scheme is either "https" or "wss", +

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

        +

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

      4. -

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

        +

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

      5. -

        If the user agent conforms to the name resolution rules in [let-localhost-be-localhost] and one of the following is true:

        +

        If the user agent conforms to the name resolution rules in [let-localhost-be-localhost] and one of the following is true:

        • -

          origin’s host is "localhost" or "localhost."

          +

          origin’s host is "localhost" or "localhost."

        • -

          origin’s host ends with ".localhost" or ".localhost."

          +

          origin’s host ends with ".localhost" or ".localhost."

        then return "Potentially Trustworthy".

        -

        Note: See § 5.2 localhost for details on the requirements here.

        +

        Note: See § 5.2 localhost for details on the requirements here.

      6. -

        If origin’s scheme is "file", return +

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

      7. -

        If origin’s scheme component is one which the user +

        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.

        +

        Note: See § 7.1 Packaged Applications for detail here.

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

        -

        Note: See § 7.2 Development Environments for detail here.

        +

        Note: See § 7.2 Development Environments for detail here.

      9. Return "Not Trustworthy".

      -

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

      +

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

      3.2. Is url potentially trustworthy?

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

      + Given a URL record (url), the following algorithm returns "Potentially Trustworthy" or "Not Trustworthy" as appropriate:

      1. -

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

        +

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

      2. -

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

        +

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

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

        -

        Note: The origin of blob: URLs is the origin of the +

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

      @@ -1185,7 +1259,7 @@

      [RFC7258] Therefore, the + 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

      @@ -1195,7 +1269,7 @@

      [VERIZON] and [COMCAST] are + 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.

      @@ -1204,7 +1278,7 @@

      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 + implementation of [WEBCRYPTOAPI] was an early experiment in locking APIs to secure contexts, and it did not walk through a context’s ancestors. The assumption was that locking the API to a resource which was itself delivered securely would be enough to ensure secure usage. The result, however, was @@ -1225,31 +1299,31 @@

      [CREDENTIAL-MANAGEMENT-1] is an example of an API that handles sensitive + information, credentials, payment instruments, and so on). [CREDENTIAL-MANAGEMENT-1] is an example of an API that handles sensitive data.
    1. 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 + accelerometer). [GEOLOCATION-API] and [MEDIACAPTURE-STREAMS] are historical examples of features that use sensor input.
    2. The ability to access information about other devices to which a user has - access. [DISCOVERY-API] and [WEB-BLUETOOTH] are good examples. + access. [DISCOVERY-API] and [WEB-BLUETOOTH] are good examples.
    3. 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]), + (e.g. [ENCRYPTED-MEDIA], Cookies [RFC6265], and [IndexedDB]), as well as identifying hardware features the user can’t easily reset.
    4. The ability to introduce some state for an origin which persists across - browsing sessions. [SERVICE-WORKERS] is a great example. + browsing sessions. [SERVICE-WORKERS] is a great example.
    5. 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. + understanding of their context. [FULLSCREEN] is a good example.
    6. 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 +

    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.

    @@ -1262,13 +1336,13 @@

    origin. Exfiltration will still be possible via increasingly esoteric mechanisms such as the contents of localStorage/sessionStorage, storage events, BroadcastChannel, and others.

    5.2. localhost

    -

    Section 6.3 of [RFC6761] lays out the resolution of localhost. and +

    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, user agents MAY treat localhost names as having potentially trustworthy origins if and only if they also adhere to the - localhost name resolution rules spelled out in [let-localhost-be-localhost] (which boil down to ensuring that localhost never resolves to a + localhost name resolution rules spelled out in [let-localhost-be-localhost] (which boil down to ensuring that localhost never resolves to a non-loopback address).

    @@ -1312,10 +1386,10 @@

    7.3. <

    • -

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

    +

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

    -
    [SecureContext]
+
    [SecureContext]
 interface SensitiveFeature {
   Promise<double> getTheSecretDouble();
 };
@@ -1323,7 +1397,7 @@ 
    7.3. <
 // Or:
 
 interface AnotherSensitiveFeature {
-  [SecureContext] void doThatPowerfulThing();
+  [SecureContext] void doThatPowerfulThing();
 };
    @@ -1333,31 +1407,31 @@

    7.4

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

    + quickly as is reasonably possible [W3C-PROCESS].

    1. If such a feature is not widely implemented, we recommend that the - specification be immediately modified to include a restriction + specification be immediately modified 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.

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

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

      +

      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. @@ -1386,312 +1460,72 @@

      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 +

      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 with class="note", like this:

      -

      Note, this is an informative note.

      -

      Conformant Algorithms

      -

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

      -

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

      - +

      Index

      Terms defined by this specification

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

      Terms defined by reference

      • - [GEOLOCATION-API] defines the following terms: + [GEOLOCATION] defines the following terms:
          -
        • getCurrentPosition() -
        • watchPosition() +
        • getCurrentPosition() +
        • watchPosition()
      • [HTML] defines the following terms:
          -
        • SharedWorker -
        • WindowOrWorkerGlobalScope -
        • current settings object -
        • domain -
        • environment -
        • global object -
        • host -
        • iframe -
        • isSecureContext -
        • non-secure context -
        • opaque origin -
        • origin -
        • port -
        • relevant settings object -
        • scheme -
        • secure context -
        • top-level browsing context -
        • tuple origin +
        • SharedWorker +
        • WindowOrWorkerGlobalScope +
        • current settings object +
        • domain +
        • environment +
        • global object +
        • host +
        • iframe +
        • isSecureContext +
        • non-secure context +
        • opaque origin +
        • origin +
        • port +
        • relevant settings object +
        • scheme +
        • secure context +
        • top-level browsing context +
        • tuple origin
      • [MIX] defines the following terms:
          -
        • a priori authenticated url +
        • a priori authenticated url
      • [URL] defines the following terms:
          -
        • origin -
        • scheme -
        • url record +
        • origin +
        • scheme +
        • url record
      • [W3C-PROCESS] defines the following terms:
          -
        • modify a specification +
        • modify a specification
      • - [WebIDL] defines the following terms: + [WEBIDL] defines the following terms:
          -
        • DOMException -
        • SecureContext -
        • SecurityError -
        • exposed +
        • DOMException +
        • SecureContext +
        • SecurityError +
        • exposed

      References

      @@ -1700,38 +1534,38 @@

      N
      [HTML]
      Anne van Kesteren; et al. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
      [LET-LOCALHOST-BE-LOCALHOST] -
      Mike West. Let 'localhost' be localhost.. URL: https://tools.ietf.org/html/draft-west-let-localhost-be-localhost -
      [RFC2119] -
      S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119 +
      Mike West. Let 'localhost' be localhost.. URL: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-let-localhost-be-localhost
      [RFC4632]
      V. Fuller; T. Li. Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan. August 2006. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc4632
      [URL]
      Anne van Kesteren. URL Standard. Living Standard. URL: https://url.spec.whatwg.org/
      [W3C-PROCESS] -
      Charles McCathie Nevile. World Wide Web Consortium Process Document. URL: https://www.w3.org/20145/Process-20150901/ -
      [WebIDL] -
      Boris Zbarsky. Web IDL. 15 December 2016. ED. URL: https://heycam.github.io/webidl/ +
      Elika J. Etemad (fantasai); Florian Rivoal. W3C Process Document. 2 November 2021. URL: https://www.w3.org/Consortium/Process/ +
      [WEBIDL] +
      Edgar Chen; Timothy Gu. Web IDL Standard. Living Standard. URL: https://webidl.spec.whatwg.org/

      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. 17 January 2019. WD. URL: https://www.w3.org/TR/credential-management-1/ +
      Mike West. Credential Management Level 1. URL: https://w3c.github.io/webappsec-credential-management/
      [DISCOVERY-API] -
      Rich Tibbett. Network Service Discovery. 12 January 2017. NOTE. URL: https://www.w3.org/TR/discovery-api/ +
      Rich Tibbett. Network Service Discovery. URL: https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html
      [ENCRYPTED-MEDIA] -
      David Dorwin; et al. Encrypted Media Extensions. 18 September 2017. REC. URL: https://www.w3.org/TR/encrypted-media/ +
      David Dorwin; et al. Encrypted Media Extensions. URL: https://w3c.github.io/encrypted-media/
      [FULLSCREEN]
      Philip Jägenstedt. Fullscreen API Standard. Living Standard. URL: https://fullscreen.spec.whatwg.org/ +
      [GEOLOCATION] +
      Marcos Caceres; Reilly Grant. Geolocation API. URL: https://w3c.github.io/geolocation-api/
      [GEOLOCATION-API] -
      Andrei Popescu. Geolocation API Specification 2nd Edition. 8 November 2016. REC. URL: https://www.w3.org/TR/geolocation-API/ +
      Andrei Popescu. Geolocation API Specification 2nd Edition. URL: https://w3c.github.io/geolocation-api/
      [IndexedDB] -
      Nikunj Mehta; et al. Indexed Database API. 8 January 2015. REC. URL: https://www.w3.org/TR/IndexedDB/ +
      Nikunj Mehta; et al. Indexed Database API. URL: https://w3c.github.io/IndexedDB/
      [MEDIACAPTURE-STREAMS] -
      Cullen Jennings; et al. Media Capture and Streams. 19 August 2021. CR. URL: https://www.w3.org/TR/mediacapture-streams/ +
      Cullen Jennings; et al. Media Capture and Streams. URL: https://w3c.github.io/mediacapture-main/
      [MIX] -
      Emily Stark; Mike West; Carlos IbarraLopez. Mixed Content Level 2. 18 September 2021. CR. URL: https://www.w3.org/TR/mixed-content/ +
      Emily Stark; Mike West; Carlos IbarraLopez. Mixed Content. URL: https://w3c.github.io/webappsec-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] @@ -1743,77 +1577,546 @@

      [SECURING-WEB]
      Mark Nottingham. Securing the Web. TAG Finding. URL: https://www.w3.org/2001/tag/doc/web-https
      [SERVICE-WORKERS] -
      Alex Russell; et al. Service Workers 1. 19 November 2019. CR. URL: https://www.w3.org/TR/service-workers-1/ +
      Jake Archibald; Marijn Kruisselbrink. Service Workers. URL: https://w3c.github.io/ServiceWorker/
      [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/ +
      Jeffrey Yasskin. Web Bluetooth. URL: https://webbluetoothcg.github.io/web-bluetooth/
      [WEBCRYPTOAPI] -
      Mark Watson. Web Cryptography API. 26 January 2017. REC. URL: https://www.w3.org/TR/WebCryptoAPI/ +
      Mark Watson. Web Cryptography API. URL: https://w3c.github.io/webcrypto/

      - - + + + \ No newline at end of file