Changes resulting from 28 February PING privacy review

index.html

@@ -1375,17 +1375,9 @@ 
           "payment-request/payment-request-canmakepayment-method-protection.https.html">
           Optionally, at the top-level browsing context's discretion,
           return a promise rejected with a "NotAllowedError" 
-            DOMException.
-            
-              This allows user agents to apply heuristics to detect and prevent
-              abuse of the canMakePayment() method for fingerprinting
-              purposes, such as creating PaymentRequest objects with a
-              variety of supported payment methods and calling
-              canMakePayment() on them one after the other. For example,
-              a user agent may restrict the number of successful calls that can
-              be made based on the top-level browsing context or the
-              time period in which those calls were made.
-            
+            DOMException. As described in section 
+            "#canmakepayment-protections">, the user agent may limit the
+            rate at which a page can call canMakePayment().
           
           Let hasHandlerPromise be a new promise.
           
@@ -5191,7 +5183,7 @@ 
         
       
     
-    class="informative">
+    id="privacy">
       
         Privacy and Security Considerations
       
@@ -5271,11 +5263,6 @@ 
           payment method identifier.
         
       
-    
-    
-      
-        Privacy Considerations
-      
       
         
           Exposing user information
@@ -5301,17 +5288,47 @@ 
           consent.
         
       
-      
-        
+       class="informative"
+         id="canmakepayment-protections"
           canMakePayment() protections
         
         
-          The canMakePayment() method enables the payee to call
-          show() if the user is ready to take advantage of the API, or
-          to fall back to a legacy checkout experience if not. Because this
-          method shares some information with the payee, user agents are
-          expected to protect the user from abuse of the method, for example,
-          by restricting the number or frequency of calls.
+          The canMakePayment() method enables the payee to determine
+          —before calling show()— whether the user is ready to take
+          advantage of the API. This enables the payee to fall back to a legacy
+          checkout experience. Because this method shares some information with
+          the payee, user agents are expected to protect the user from abuse of
+          the method. For example, user agents may reduce user fingerprinting
+          by:
+        
+        
+          Allowing the user to configure the user agent to turn off
+          canMakePayment().
+          
+          informing the user of what data is shared by
+          canMakePayment();
+          
+          Rate-limiting the frequency of calls to canMakePayment()
+          with different parameters.
+          
+        
+        
+          For rate-limiting the user agent might look at repeated calls from:
+        
+        
+          the same effective top-level domain plus one (eTLD+1).
+          
+          the top-level browsing context. Alternatively, the user agent may
+          block access to the API entirely for origins know to be bad actors.
+          
+          for an iframe, the origin of the iframe content.
+          
+        
+        
+          These rate-limiting techniques intend to increase the cost associated
+          with repeated calls, whether it is the cost of managing multiple
+          eTLDs or the user experience friction of opening multiple windows
+          (tabs or pop-ups).