Re: [w3c/payment-request] Changes resulting from 28 February PING privacy review (#843)

marcoscaceres requested changes on this pull request.

FWIW, rate limiting seems still feels ineffectual. 

> -          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 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:
+        </p>
+        <ul data-link-for="PaymentRequest">
+          <li>allowing the user to configure the user agent to turn off
+          <a>canMakePayment()</a>;
+          </li>
+          <li>informing the user when <a>canMakePayment()</a> is called;

This seem impractical. I'm against including this suggestion. 

> -          <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 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:
+        </p>
+        <ul data-link-for="PaymentRequest">
+          <li>allowing the user to configure the user agent to turn off
+          <a>canMakePayment()</a>;

```suggestion
          <a>canMakePayment()</a>.
```

> -          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 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:
+        </p>
+        <ul data-link-for="PaymentRequest">
+          <li>allowing the user to configure the user agent to turn off
+          <a>canMakePayment()</a>;
+          </li>
+          <li>informing the user when <a>canMakePayment()</a> is called;
+          </li>
+          <li>rate-limiting the frequency of calls to <a>canMakePayment()</a>

```suggestion
          <li>Rate-limiting the frequency of calls to <a>canMakePayment()</a>
```

> +        </p>
+        <ul data-link-for="PaymentRequest">
+          <li>allowing the user to configure the user agent to turn off
+          <a>canMakePayment()</a>;
+          </li>
+          <li>informing the user when <a>canMakePayment()</a> is called;
+          </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);

```suggestion
          <li>the same effective top-level domain plus one (eTLD+1).
```

> +          <li>allowing the user to configure the user agent to turn off
+          <a>canMakePayment()</a>;
+          </li>
+          <li>informing the user when <a>canMakePayment()</a> is called;
+          </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;

```suggestion
          <li>the top-level browsing context - or block access to the API entirely for origins know to be bad actors.</li> 
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-request/pull/843#pullrequestreview-209891358