Changes resulting from 28 February PING privacy review (#843)

* Changes resulting from 28 February PING privacy review
 https://www.w3.org/2019/02/28-privacy-minutes

Specifically:

 * Merged the "Security and Privacy" and "Privacy" considerations sections
  into a single "Security and Privacy Considerations"

 * Added a forward pointer from 3.5 to the canMakePayment() protections section (in security and privacy considerations). Removed the Note in the algorithm of 3.5, and merged it with the (rewritten) protections section.

 * Expanded the canMakePayment protections section based on PING conversation.

* One S&P section is normative, the others are informative. Adjusted markup accordingly.

* - Editorial tweaks from Marcos
- Removed "alert the user" as an idea; deemed impractical

* Added back canMakePayment() bullet about informing the user
about what data is shared, but rephrased to sound less like
it has to be real-time

* Update index.html

Co-Authored-By: ianbjacobs 

* Update index.html

Co-Authored-By: ianbjacobs 

* Update index.html

(Marcos and Ian edited.)

Co-Authored-By: ianbjacobs 

* Update index.html

Co-Authored-By: ianbjacobs 

* Update index.html

* Update index.html

* Update index.html

Co-Authored-By: ianbjacobs 

* Update index.html

* Update index.html

* Update index.html

* removed inform user after more conversation with marcos

* Update index.html

Co-Authored-By: ianbjacobs 

* tidy

Author: ianbjacobs

index.html

@@ -1375,17 +1375,9 @@ 
           "payment-request/payment-request-canmakepayment-method-protection.https.html">
           Optionally, at the <a>top-level browsing contexta>'s discretion,
           return <a>a promise rejected witha> a "<a>NotAllowedErrora>" <a>
-            DOMExceptiona>.
-            <p class="note" data-link-for="PaymentRequest">
-              This allows user agents to apply heuristics to detect and prevent
-              abuse of the <a>canMakePayment()a> method for fingerprinting
-              purposes, such as creating <a>PaymentRequesta> objects with a
-              variety of supported <a>payment methodsa> and calling
-              <a>canMakePayment()a> 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 <a>top-level browsing contexta> or the
-              time period in which those calls were made.
-            p>
+            DOMExceptiona>. As described in section <a href=
+            "#canmakepayment-protections">a>, the user agent may limit the
+            rate at which a page can call <a>canMakePayment()a>.
           li>
           <li>Let <var>hasHandlerPromisevar> be <a>a new promisea>.
           li>
@@ -5191,7 +5183,7 @@ 
         ol>
       section>
     section>
-    <section class="informative">
+    <section id="privacy">
       <h2>
         Privacy and Security Considerations
       h2>
@@ -5271,11 +5263,6 @@ 
           <a>payment method identifiera>.
         p>
       section>
-    section>
-    <section id="privacy">
-      <h2>
-        Privacy Considerations
-      h2>
       <section>
         <h2>
           Exposing user information
@@ -5301,17 +5288,49 @@ 
           consent.
         p>
       section>
-      <section>
-        <h2>
-          canMakePayment() protections
+      <section class="informative">
+        <h2 id="canmakepayment-protections">
+          <code>canMakePayment()code> protections
         h2>
         <p data-link-for="PaymentRequest">
-          The <a>canMakePayment()a> method enables the payee to call
-          <a>show()a> 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 <a>canMakePayment()a> method enables the payee to determine —
+          before calling <a>show()a> — whether the user agent knows of any
+          <a>payment handlersa> available to the user that support the
+          <a>payment methodsa> provided to the <a>PaymentRequesta>
+          <a data-lt="PaymentRequest.PaymentRequest()">constructora>. If no
+          <a>payment handlersa> support the <a>payment methodsa>, this
+          enables the payee to fall back to a legacy checkout experience.
+          Because this method shares some potentially unique information with
+          the payee, user agents are expected to protect the user from abuse of
+          the method. For example, user agents can reduce user fingerprinting
+          by:
+        p>
+        <ul data-link-for="PaymentRequest">
+          <li>Allowing the user to configure the user agent to turn off
+          <a>canMakePayment()a>, which would return <a>a promise rejected
+          witha> a "<a>NotAllowedErrora>" <a>DOMExceptiona>.
+          li>
+          <li>Rate-limiting the frequency of calls to <a>canMakePayment()a>
+          with different parameters.
+          li>
+        ul>
+        <p>
+          For rate-limiting the user agent might look at repeated calls from:
+        p>
+        <ul>
+          <li>the same effective top-level domain plus one (eTLD+1).
+          li>
+          <li>the top-level browsing context. Alternatively, the user agent may
+          block access to the API entirely for origins know to be bad actors.
+          li>
+          <li>the origin of an <a>iframea> or popup window.
+          li>
+        ul>
+        <p>
+          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).
         p>
       section>
     section>