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

ianbjacobs · web-flow · commit 3f644f46ce61 · 2019-03-12T17:30:24.000-05:00
* 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 <ij@w3.org> * Update index.html Co-Authored-By: ianbjacobs <ij@w3.org> * Update index.html (Marcos and Ian edited.) Co-Authored-By: ianbjacobs <ij@w3.org> * Update index.html Co-Authored-By: ianbjacobs <ij@w3.org> * Update index.html * Update index.html * Update index.html Co-Authored-By: ianbjacobs <ij@w3.org> * Update index.html * Update index.html * Update index.html * removed inform user after more conversation with marcos * Update index.html Co-Authored-By: ianbjacobs <ij@w3.org> * tidy
diff --git a/index.html b/index.html
@@ -1375,17 +1375,9 @@ <h2>
           "payment-request/payment-request-canmakepayment-method-protection.https.html">
           Optionally, at the <a>top-level browsing context</a>'s discretion,
           return <a>a promise rejected with</a> a "<a>NotAllowedError</a>" <a>
-            DOMException</a>.
-            <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>PaymentRequest</a> objects with a
-              variety of supported <a>payment methods</a> 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 context</a> or the
-              time period in which those calls were made.
-            </p>
+            DOMException</a>. 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>hasHandlerPromise</var> be <a>a new promise</a>.
           </li>
@@ -5191,7 +5183,7 @@ <h2>
         </ol>
       </section>
     </section>
-    <section class="informative">
+    <section id="privacy">
       <h2>
         Privacy and Security Considerations
       </h2>
@@ -5271,11 +5263,6 @@ <h2>
           <a>payment method identifier</a>.
         </p>
       </section>
-    </section>
-    <section id="privacy">
-      <h2>
-        Privacy Considerations
-      </h2>
       <section>
         <h2>
           Exposing user information
@@ -5301,17 +5288,49 @@ <h2>
           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 handlers</a> available to the user that support the
+          <a>payment methods</a> provided to the <a>PaymentRequest</a>
+          <a data-lt="PaymentRequest.PaymentRequest()">constructor</a>. If no
+          <a>payment handlers</a> support the <a>payment methods</a>, 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
+          with</a> a "<a>NotAllowedError</a>" <a>DOMException</a>.
+          </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>iframe</a> 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>
