From 6b8a2c76d5eb5ed666a31e4207b9e2a3cf3d49ea Mon Sep 17 00:00:00 2001 From: Douglas Creager Date: Wed, 27 Jun 2018 11:13:56 -0400 Subject: [PATCH 1/7] Handle errors in different phases differently This patch clarifies the different phases that happen while servicing a request. A network error occurs during one of those phases, and we now handle errors differently depending on which phase they occur in: - `include_subdomains` policies can only be used to generate reports about DNS resolution errors, since the policy author can only confirm ownership of the DNS tree, and not of all of the servers that those domain names resolve to. - If the resolved IP address for an origin changes between when a policy is received, and when its used to generate a report, we don't report any details about the connection and application phases, and only report that the IP address changed. This prevents DNS rebinding attacks. --- index.html | 151 +++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 146 insertions(+), 5 deletions(-) diff --git a/index.html b/index.html index bcc3968..2ef145e 100644 --- a/index.html +++ b/index.html @@ -165,6 +165,7 @@

Dependencies

  • 200 status code
  • 5xx status code
  • local cache
    • +
  • persistent connections
  • request
  • request method
  • resource representation
    • @@ -274,6 +275,43 @@

    Network requests

    HTTP-network fetch algorithm.

    +

    + Regardless of which fetch algorithm and which underlying application and + transport protocols are used, servicing a network request consists + of the following phases: +

    + +
      +
    1. + DNS resolution: The user agent uses the Domain Name System + [[RFC1034]] to resolve a domain name into an IP address of a + server can that service HTTP requests to that domain. +
      2. + +
    2. + Secure connection establishment: The user agent opens a + connection to the server, and establishes a secure channel over + this connection. +
      3. + +
    3. + Transmission of request and response: Once the secure + channel is established, the user agent can transmit the HTTP request, + and receive the response from the server. +
      4. +
    + +

    + The only mandatory phase is the transmission of request and + response; the other phases might not be needed for every network + request. For instance, DNS results can be cached locally in the + user agent, eliminating DNS resolution for future requests to the + same domain. Similarly, HTTP persistent connections allow open + connections to be shared for multiple requests to the same origin. + However, if multiple phases occur, they will occur in the above + order. +

    +

    A network request is successful if the user agent is able @@ -299,6 +337,28 @@

    Network errors

    a string.

    +

    + Each network error has a phase, which describes which phase the + error occurred in: +

    + +
    +
    dns
    +
    the error occurred during DNS resolution
    + +
    connection
    +
    + the error occurred during secure connection establishment +
    + +
    application
    +
    + the error occurred during the transmission of request and + response +
    +
    +

    There are several predefined network error types defined in . @@ -315,6 +375,12 @@

    NEL policies

    delivered to the user agent via HTTP response headers.

    +

    + Each NEL policy has a received IP address, which is the + IP address of the server that the user agent received this NEL + policy from. +

    +

    Each NEL policy has an origin. @@ -611,6 +677,12 @@

    Process policy headers

    +
    received IP address
    +
    + the IP address of the server that the user agent received + response from +
    +
    origin
    origin
    @@ -803,6 +875,13 @@

    Generate a network error report

    fetch and when it was completed or aborted by the user agent. +
    phase
    +
    + If request failed, the phase of its + network error. If request succeeded, + "application". +
    +
    type
    If request failed, the type of its @@ -812,6 +891,33 @@

    Generate a network error report

    +
  • + If request body's server_ip property is + non-empty, and not equal to policy's received IP + address: + +
      +
    1. + Set request body's phase to + dns. +
      2. +
    2. + Set request body's type to + dns.changed_address. +
      3. +
    3. + Clear request body's status_code and + elapsed_time properties. +
      4. +
    +
    • + +
  • + If policy's subdomains flag is include, + and request body's phase property is not + dns, abort these steps. +
    • +

  • Queue the report for delivery via the Reporting API. [[!REPORTING]]

    @@ -849,16 +955,40 @@

    Predefined network error types

    and/or one or multiple subgroups.

    -
    +
    +

    DNS resolution errors

    + +

    + All of the network errors in this section occur during the + DNS resolution phase, and therefore have a phase of dns. +

    + +
    dns.unreachable
    DNS server is unreachable
    dns.name_not_resolved
    DNS server responded but is unable to resolve the address
    dns.failed
    Request to the DNS server failed due to reasons not covered by previous errors
    +
    dns.changed_address
    +
    + Indicates that the resolved IP address for a request's origin has + changed since the corresponding NEL policy was received +
    +
    + +
    +

    Secure connection establishment errors

    -
    +

    + All of the network errors in this section occur during the + secure connection establishment phase, and therefore have a + phase of connection. +

    + +
    tcp.timed_out
    TCP connection to the server timed out
    @@ -884,7 +1014,7 @@

    Predefined network error types

    The TCP connection failed due to reasons not covered by previous errors
    -
    +
    tls.version_or_cipher_mismatch
    The TLS connection was aborted due to version or cipher mismatch
    @@ -915,8 +1045,18 @@

    Predefined network error types

    tls.failed
    The TLS connection failed due to reasons not covered by previous errors
    +
    + +
    +

    Transmission of request and response errors

    -
    +

    + All of the network errors in this section occur during the + transmission of request and response phase, and therefore + have a phase of application. +

    + +
    http.protocol.error
    The connection was aborted due to an HTTP protocol error
    @@ -931,13 +1071,14 @@

    Predefined network error types

    -
    +
    abandoned
    User aborted the resource fetch before it is complete
    unknown
    error type is unknown
    +
    From 6d6197f46bf4fd9c48e162b25cb8d584806a91b5 Mon Sep 17 00:00:00 2001 From: Douglas Creager Date: Tue, 3 Jul 2018 11:17:21 -0400 Subject: [PATCH 2/7] add examples and privacy notes --- index.html | 318 +++++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 294 insertions(+), 24 deletions(-) diff --git a/index.html b/index.html index 2ef145e..2d6c7b4 100644 --- a/index.html +++ b/index.html @@ -131,6 +131,15 @@

    Conformance requirements

    Dependencies

    +
    DNS
    +
    +

    The following terms are defined in the DNS specification: [[!RFC1034]]

    +
      +
    • domain name
      • +
    • domain namespace tree
      • +
    • resolver
      • +
    +
    Fetch

    The following terms are defined in the Fetch specification: [[!FETCH]]

    @@ -171,7 +180,7 @@

    Dependencies

  • resource representation
  • response
  • response headers
    • -
  • server
    • +
  • server
  • status code
    • @@ -903,7 +912,7 @@

    Generate a network error report

  • Set request body's type to - dns.changed_address. + dns.address_changed.
  • Clear request body's status_code and @@ -971,7 +980,7 @@

    DNS resolution errors

    DNS server responded but is unable to resolve the address
    dns.failed
    Request to the DNS server failed due to reasons not covered by previous errors
    -
    dns.changed_address
    +
    dns.address_changed
    Indicates that the resolved IP address for a request's origin has changed since the corresponding NEL policy was received @@ -1110,25 +1119,6 @@

    Sample Policy Definitions

    > GET / HTTP/1.1 > Host: example.com -< HTTP/1.1 200 OK -< ... -< Report-To: {"group": "network-errors", "max_age": 2592000, - "endpoints": [{"url": "https://example.com/upload-reports"}]} -< NEL: {"report_to": "network-errors", "max_age": 2592000, "include_subdomains": true} - - -

    - This NEL header defines a similar NEL policy to the - previous example, instructing the user agent to report network errors - about example.com to the endpoint group named - network-errors. Because of the include_subdomains - field, this policy also applies to all subdomains of - example.com.

    - - 
    -> GET / HTTP/1.1
-> Host: example.com
-
 < HTTP/1.1 200 OK
 < ...
 < NEL: {"max_age": 0}
@@ -1216,6 +1206,215 @@ 
    Sample Network Error Reports
    
         
    
 
       
+
+      
    
+        
    DNS misconfiguration
    
+
+        
    +> GET / HTTP/1.1
+> Host: example.com
+
+< HTTP/1.1 200 OK
+< ...
+< Report-To: {"group": "network-errors", "max_age": 2592000,
+              "endpoints": [{"url": "https://example.com/upload-reports"}]}
+< NEL: {"report_to": "network-errors", "max_age": 2592000, "include_subdomains": true}
+        
    
+
+        
    
+        This NEL header allows the owner of
+        example.com to detect when they have misconfigured their
+        DNS servers — for instance, when they have forgotten to add a new
+        resource record resolving new-subdomain.example.com to an
+        IP address.  If a user agent tries to make a request to
+        new-subdomain.example.com, it might generate the following
+        report:
+        
    
+
+        
    +{
+  "age": 0,
+  "type": "network-error",
+  "url": "https://new-subdomain.example.com/",
+  "body": {
+    "uri": "https://new-subdomain.example.com/",
+    "sampling_fraction": 1.0,
+    "server_ip": "",
+    "protocol": "http/1.1",
+    "method": "GET",
+    "status_code": 0,
+    "elapsed_time": 48,
+    "type": "dns.name_not_resolved"
+  }
+}
+        
    
+
+      
    
+
+      
    
+        
    Origins with multiple IP addresses
    
+
+        
    
+        For origins whose domain name resolves to multiple IP
+        addresses, NEL will sometimes "downgrade" an error report, providing
+        less information about the cause of the error, since it cannot verify
+        that the owner of the origin is the same as the owner of the
+        server handling the request.
+        
    
+
+        
    
+        As an example, assume that example.com is handled by three
+        servers, each with a different IP address.  The owner of the
+        service configures DNS to resolve example.com to
+        192.168.0.1, 192.168.0.2, and
+        192.168.0.3, and relies on user agents to balance their
+        requests across these three IP addresses.  The service owner delivers
+        the following NEL policy:
+        
    
+
+        
    +> GET / HTTP/1.1
+> Host: example.com
+
+< HTTP/1.1 200 OK
+< ...
+< Report-To: {"group": "network-errors", "max_age": 2592000,
+              "endpoints": [{"url": "https://example.com/upload-reports"}]}
+< NEL: {"report_to": "network-errors", "max_age": 2592000,
+        "success_fraction": 1.0, "failure_fraction": 1.0}
+        
    
+
+        
    
+        Given the above, consider the following sequence of events:
+        
    
+
+        
      
+          
    1. 
+            
      
+            The user agent sends a request to 192.168.0.1,
+            and receives a successful response from the server.
+            This response includes the above NEL policy, and the user
+            agent sets the policy's received IP address to
+            192.168.0.1.  Since the received IP address
+            matches the server's IP address (which it must for any
+            successful request), it generates the following NEL report:
+            
      
+
+            
      +{
+  "age": 0,
+  "type": "network-error",
+  "url": "https://example.com/",
+  "body": {
+    "uri": "https://example.com/",
+    "sampling_fraction": 1.0,
+    "server_ip": "192.168.0.1",
+    "protocol": "http/1.1",
+    "method": "GET",
+    "status_code": 200,
+    "elapsed_time": 57,
+    "type": "ok"
+  }
+}
+            
      
+          
      2. 
+
+          
    2. 
+            
      
+            The user agent sends a new request to
+            192.168.0.2, and receives another successful
+            response.  This response also includes the NEL policy,
+            and the user agent updates the policy's received IP address
+            to 192.168.0.2.  Since the received IP address
+            matches the server's IP address (which it must for any
+            successful request), it generates the following NEL report:
+            
      
+
+            
      +{
+  "age": 0,
+  "type": "network-error",
+  "url": "https://example.com/",
+  "body": {
+    "uri": "https://example.com/",
+    "sampling_fraction": 1.0,
+    "server_ip": "192.168.0.2",
+    "protocol": "http/1.1",
+    "method": "GET",
+    "status_code": 200,
+    "elapsed_time": 34,
+    "type": "ok"
+  }
+}
+            
      
+          
      3. 
+
+          
    3. 
+            
      
+            The user agent then tries to send a request to
+            192.168.0.3, but isn't able to establish a connection
+            to the server.  The user agent still has the NEL policy in
+            the policy cache, and would ideally use this policy to
+            generate a tcp.timed_out report about the failed
+            network request.  However, the because policy's received
+              IP address (192.168.0.2) doesn't match the IP
+            address that this request was sent to, the user agent cannot
+            verify that the server at 192.168.0.3 is actually owned
+            by the owners of example.com.  The user agent must
+            therefore downgrade the report to dns.address_changed:
+            
      
+
+            
      +{
+  "age": 0,
+  "type": "network-error",
+  "url": "https://example.com/",
+  "body": {
+    "uri": "https://example.com/",
+    "sampling_fraction": 1.0,
+    "server_ip": "192.168.0.3",
+    "protocol": "http/1.1",
+    "method": "GET",
+    "status_code": 0,
+    "elapsed_time": 62,
+    "type": "dns.address_changed"
+  }
+}
+            
      
+          
      4. 
+
+          
    4. 
+            
      
+            The user agent then tries to send another request to
+            192.168.0.1, but once again isn't able to establish a
+            connection to the server.  Even though the user agent received the
+            NEL policy from 192.168.0.1 at some point in the
+            past, the policy's received IP address only records where it
+            was most recently received from — in this case,
+            192.168.0.2.  The user agent must therefore downgrade
+            the report to dns.address_changed:
+            
      
+
+            
      +{
+  "age": 0,
+  "type": "network-error",
+  "url": "https://example.com/",
+  "body": {
+    "uri": "https://example.com/",
+    "sampling_fraction": 1.0,
+    "server_ip": "192.168.0.1",
+    "protocol": "http/1.1",
+    "method": "GET",
+    "status_code": 0,
+    "elapsed_time": 59,
+    "type": "dns.address_changed"
+  }
+}
+            
      
+          
      5. 
+        
    
+      
    
     
 
     
    
@@ -1249,9 +1448,80 @@ 
    Reporting of Third-party Subresource Fetch Failures
    
     
    
       
    Privacy Considerations
    
 
-      
    NEL provides network error reports that could expose new information about the user's network configuration. For example, an attacker could abuse NEL reporting to probe users network configuration. Also, similar to HSTS, HPKP, and pinned CSP policies, the stored NEL policy could be used as a "supercookie" by setting a distinct policy with a custom (per-user) reporting URI to act as an identififer in combination with (or instead of) HTTP cookies.
    
+      
    
+      NEL provides network error reports that could expose new information about
+      the user's network configuration. For example, an attacker could abuse NEL
+      reporting to probe the user's network configuration, or to scan for
+      servers on the user's internal network. Also, similar to HSTS, HPKP, and
+      pinned CSP policies, the stored NEL policy could be used as a
+      "supercookie" by setting a distinct policy with a custom (per-user)
+      reporting URI to act as an identififer in combination with (or instead of)
+      HTTP cookies.
+      
    
 
-      
    To mitigate some of the above risks, NEL registration is restricted to trustworthy origins, and delivery of network error reports is similarly restricted to trustworthy origins. This disallows a transient HTTP MITM from trivially abusing NEL as a persistent tracker.
    
+      
    
+      To mitigate some of the above risks, NEL registration is restricted to
+      trustworthy origins, and delivery of network error reports is
+      similarly restricted to trustworthy origins. This disallows a
+      transient HTTP MITM from trivially abusing NEL as a persistent
+      tracker.
+      
    
+
+      
    
+      NEL is intended to augment existing server-side monitoring.  NEL reports
+      should only be sent to the owner of the service being requested.  For
+      errors that occur during DNS resolution, the user agent MUST ensure
+      that the NEL policy was received from the owner of the domain
+        namespace tree that contains the policy origin.  For errors
+      that occur during secure connection establishment or
+      transmission of request and response, the user agent MUST ensure
+      that the NEL policy was received from the owner of the
+      server that the request was sent to.
+      
    
+
+      
    
+      This rationale explains the treatment of the received IP address
+      and subdomains flag of a NEL policy.  By checking that the
+      policy's received IP address matches the IP address of the
+      server, NEL extends the trust boundary of the policy to include not
+      just the policy's origin, but also the
+      specific server that the user agent is communicating with.  This helps
+      prevent (for instance) DNS rebinding attacks, where an attacker delivers a
+      long-lived NEL policy from a server that they own, and then changes
+      their name servers to resolve the policy origin to a server they
+      don't control.  Without the received IP address verification, this
+      would cause user agents to send reports about the second server to the
+      attacker.
+      
    
+
+      
    
+      Similarly, subdomain NEL policies are
+      limited, and can only be used to generate reports about subdomains of the
+      policy origin during the DNS resolution phase of a
+      request.  During this phase, there is no server to verify
+      ownership of, and the fact that the policy was received from a superdomain
+      of the request's origin is enough to establish ownership of
+      the error.  This allows the owners of a particular portion of the
+      domain namespace tree to use NEL to detect  errors, while preventing them from
+      using malicious DNS entries to collect information about servers they
+      don't control.
+      
    
+
+      
    
+      To prevent information leakage, NEL reports about a request MUST
+      NOT contain any information that is not visible to the server when
+      processing the request.  For errors during DNS resolution, a
+      NEL report MUST only contain information available from DNS itself.  This
+      prevents servers from abusing NEL to collect more information about
+      their users than they already have access to.
+      
    
+
+      
    
+      As an example, NEL reports specifically do not contain any information
+      about which DNS resolver was used to resolve a request's
+      domain name into an IP address.
+      
    
 
       
    In addition to above restrictions, the user agents MUST:
    
 

From ab175da461da41f33ade0b43f807dbf7a8b5e942 Mon Sep 17 00:00:00 2001
From: Douglas Creager 
Date: Tue, 3 Jul 2018 11:21:47 -0400
Subject: [PATCH 3/7] edits from jyasskin

---
 index.html | 27 ++++++++++++++++++++-------
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/index.html b/index.html
index 2d6c7b4..cb443e1 100644
--- a/index.html
+++ b/index.html
@@ -149,6 +149,7 @@ 
    Dependencies
    
             
  • HTTP-network fetch
    • 
             
  • HTTP-network-or-cache fetch
    • 
             
  • redirect status
    • 
+            
  • response
    •
    HSTS
    @@ -178,7 +179,6 @@

    Dependencies

  • request
  • request method
  • resource representation
    • -
  • response
  • response headers
  • server
  • status code
    • @@ -321,6 +321,11 @@

    Network requests

    order.

    +

    + We would like to move the definition of these phases into [[FETCH]] so + that they are more reusable. +

    +

    A network request is successful if the user agent is able @@ -690,6 +695,10 @@

    Process policy headers

    the IP address of the server that the user agent received response from + +

    + Plumb this through more explicitly in [[FETCH]]. +

    origin
    @@ -901,23 +910,27 @@

    Generate a network error report

  • - If request body's server_ip property is + If report body's server_ip property is non-empty, and not equal to policy's received IP address:
    1. - Set request body's phase to - dns. -
      2. + Set report body's phase to + dns.
    2. - Set request body's type to + Set report body's type to dns.address_changed.
    3. - Clear request body's status_code and + Clear report body's status_code and elapsed_time properties.
      4. +
    4. + If the user agent has added any additional fields to report + body, clear any that are derived from information not + available during DNS resolution. +
    • From 9ca7a68fcaf45c08abe76732399c205094eb649a Mon Sep 17 00:00:00 2001 From: Douglas Creager Date: Sat, 7 Jul 2018 09:41:11 -0400 Subject: [PATCH 4/7] =?UTF-8?q?reword=20privacy=20=C2=A7;=20use=20assert?= =?UTF-8?q?=20in=20report=20generation?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- index.html | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/index.html b/index.html index cb443e1..4858b42 100644 --- a/index.html +++ b/index.html @@ -617,7 +617,7 @@

    Process policy headers

    policy cache accordingly.

    -
      +
      1. Abort these steps if any of the following conditions are true: @@ -757,7 +757,7 @@

        Choose a policy for an origin

        generate reports for network requests to origin.

        -
          +
          1. If there is an entry in the policy cache for origin: @@ -804,7 +804,7 @@

            Generate a network error report

            policy, and queues it for delivery.

            -
              +
              1. If the result of executing the is-origin-trustworthy algorithm @@ -927,9 +927,9 @@

                Generate a network error report

                elapsed_time properties.
              2. - If the user agent has added any additional fields to report - body, clear any that are derived from information not - available during DNS resolution. + Assert: All fields in report body that are derived from + information not available during DNS resolution have been + cleared.
              @@ -1483,12 +1483,12 @@

              Privacy Considerations

              NEL is intended to augment existing server-side monitoring. NEL reports should only be sent to the owner of the service being requested. For - errors that occur during DNS resolution, the user agent MUST ensure - that the NEL policy was received from the owner of the domain - namespace tree that contains the policy origin. For errors - that occur during secure connection establishment or - transmission of request and response, the user agent MUST ensure - that the NEL policy was received from the owner of the + errors that occur during DNS resolution, NEL reports are only + generated when the NEL policy was received from the owner of the + domain namespace tree that contains the policy origin. For + errors that occur during secure connection establishment or + transmission of request and response, NEL reports are only + generated when the NEL policy was received from the owner of the server that the request was sent to.

              @@ -1522,10 +1522,10 @@

              Privacy Considerations

              - To prevent information leakage, NEL reports about a request MUST - NOT contain any information that is not visible to the server when + To prevent information leakage, NEL reports about a request do not + contain any information that is not visible to the server when processing the request. For errors during DNS resolution, a - NEL report MUST only contain information available from DNS itself. This + NEL report only contains information available from DNS itself. This prevents servers from abusing NEL to collect more information about their users than they already have access to.

              From 1f437781e058da47e15ab3c5c302ca7a4cddb8dd Mon Sep 17 00:00:00 2001 From: Douglas Creager Date: Mon, 9 Jul 2018 15:52:41 -0400 Subject: [PATCH 5/7] edits from yoav --- index.html | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/index.html b/index.html index 253825f..22aeb9a 100644 --- a/index.html +++ b/index.html @@ -931,6 +931,20 @@

              Generate a network error report

              cleared.
            + +

            + This step "downgrades" a NEL report if the IP addresses of the + server and the policy don't match. + This is a privacy protection, ensuring that NEL reports are only sent + to the owner of the service that the report describes. If the IP + addresses don't match, then the user agent can only verify that the + NEL policy was sent by the owner of the origin's + domain name; it cannot verify that the policy was sent by the + owner of the server this domain name resolves to. We + therefore downgrade the report to only contain information about + DNS resolution. See for + more details. +

          2. @@ -1473,10 +1487,10 @@

            Privacy Considerations

            To mitigate some of the above risks, NEL registration is restricted to - trustworthy origins, and delivery of network error reports is - similarly restricted to trustworthy origins. This disallows a - transient HTTP MITM from trivially abusing NEL as a persistent - tracker. + potentially trustworthy origins, and delivery of network error + reports is similarly restricted to potentially trustworthy origins. + This disallows a transient HTTP MITM from trivially abusing NEL as a + persistent tracker.

            From b8f8f476539e96785eb867c8ff4a703c9cf9ae6e Mon Sep 17 00:00:00 2001 From: Douglas Creager Date: Tue, 10 Jul 2018 09:04:49 -0400 Subject: [PATCH 6/7] fix name of potentially trustworthy algo --- index.html | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/index.html b/index.html index 22aeb9a..2be6b35 100644 --- a/index.html +++ b/index.html @@ -225,7 +225,8 @@

            Dependencies

            The following terms are defined in the Secure Contexts specification: [[!SECURE-CONTEXTS]]

              -
            • the is-origin-trustworthy algorithm
              • +
            • the "Is + origin potentially trustworthy?" algorithm
            • potentially trustworthy origin
            @@ -622,9 +623,10 @@

            Process policy headers

            • - The result of executing the is-origin-trustworthy algorithm - on request's origin is not - Potentially Trustworthy. + The result of executing the "Is origin potentially + trustworthy?" algorithm on request's + origin is not Potentially + Trustworthy.
            • @@ -806,9 +808,10 @@

              Generate a network error report

              1. - If the result of executing the is-origin-trustworthy algorithm - on request's origin is not - Potentially Trustworthy, abort these steps. + If the result of executing the "Is origin potentially + trustworthy?" algorithm on request's origin is + not Potentially Trustworthy, abort these + steps.
              2. From 87386f7c362f6860e62eda59af9b0a2a48dc56a2 Mon Sep 17 00:00:00 2001 From: Douglas Creager Date: Tue, 10 Jul 2018 09:52:06 -0400 Subject: [PATCH 7/7] fix some typos --- index.html | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/index.html b/index.html index 2be6b35..d593fcc 100644 --- a/index.html +++ b/index.html @@ -227,7 +227,7 @@

                Dependencies

                • the "Is origin potentially trustworthy?" algorithm
                  • -
                • potentially trustworthy origin
                  • +
                • potentially trustworthy origin
                URL
                @@ -945,8 +945,8 @@

                Generate a network error report

                domain name; it cannot verify that the policy was sent by the owner of the server this domain name resolves to. We therefore downgrade the report to only contain information about - DNS resolution. See for - more details. + DNS resolution. See and + for more details.

                3. @@ -997,9 +997,9 @@

                Predefined network error types

                DNS resolution errors

                - All of the network errors in this section occur during the - DNS resolution phase, and therefore have a phase of dns. + All of the network errors in this section occur during DNS + resolution, and therefore have a phase + of dns.

                @@ -1021,9 +1021,9 @@

                DNS resolution errors

                Secure connection establishment errors

                - All of the network errors in this section occur during the - secure connection establishment phase, and therefore have a - phase of connection. + All of the network errors in this section occur during secure + connection establishment, and therefore have a phase of connection.

                @@ -1090,8 +1090,8 @@

                Transmission of request and response errors

                All of the network errors in this section occur during the - transmission of request and response phase, and therefore - have a phase of application. + transmission of request and response, and therefore have a phase of application.

                @@ -1405,7 +1405,7 @@

                Origins with multiple IP addresses

                "protocol": "http/1.1", "method": "GET", "status_code": 0, - "elapsed_time": 62, + "elapsed_time": 0, "type": "dns.address_changed" } } @@ -1436,7 +1436,7 @@

                Origins with multiple IP addresses

                "protocol": "http/1.1", "method": "GET", "status_code": 0, - "elapsed_time": 59, + "elapsed_time": 0, "type": "dns.address_changed" } }