Changes resulting from 28 February PING privacy review #843

ianbjacobs · 2019-03-01T20:34:22Z

Based on discussion at the Privacy Interest Group call yesterday, I took an action to propose some changes; see the minutes for details:
https://www.w3.org/2019/02/28-privacy-minutes

Specifically:

Merged the "Privacy and Security Considerations" and "Privacy Considerations" sections into a single section ("Privacy and Security Considerations").
Added a forward pointer from 3.5 to the canMakePayment() protections section (in security and privacy considerations). Removed the Note that was in the middle of the algorithm of 3.5, and merged it with the (rewritten) canMakePayment protections section.
Expanded the canMakePayment protections section based on PING conversation.

The following tasks have been completed:

Confirmed there are no ReSpec errors/warnings.
Has undergone security/privacy review (link)

NOTE: I will also point PING at the edit.

Preview | Diff

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.

npdoty · 2019-03-01T21:07:35Z

Combining the privacy and security considerations section and the privacy considerations section has one problem: the high-level category is listed as non-normative, but some of the subsections have normative requirements in them. I think you could fix that by removing the marking of the high-level section as informative, and then evaluating each subsection to see whether it's informative or normative.

rsolomakhin

Addition to "canmakepayment-protections" section LGTM

…rkup accordingly.

ianbjacobs · 2019-03-01T21:20:00Z

@npdoty, thanks for catching that. I have adopted your proposal. I do not believe I have changed what was already the case - a single normative section under Security and Privacy Considerations.

marcoscaceres · 2019-03-01T21:26:07Z

Thanks for making a start on this! I’ll try to review it over the weekend.

pes10k · 2019-03-02T00:33:55Z

Thanks much for these @ianbjacobs.

Under mitigations / protections, I'm wondering if there isn't the possibility for greater protections / stronger suggestions here. For example, is there any plausible any scenario where multiple iframes would need to call the canMakePayment endpoint in the same top-level context?
What are the avenues for suggesting / proposing that the mitigations become normative?
@samuelweiler had suggestions / concerns about the current proposal and negotiating what payment fields are shared (looks like the options argument would be a natural fit). Will that be part of these changes?

Thanks much!

ianbjacobs · 2019-03-02T01:32:23Z

HI @snyderp,

Under mitigations / protections, I'm wondering if there isn't the possibility for greater protections /
stronger suggestions here. For example, is there any plausible any scenario where multiple iframes
would need to call the canMakePayment endpoint in the same top-level context?

That was one of the suggestions from the call that made it into the pull request: to limit in the face of multiple calls with different parameters from the top-level browsing context. Are there concrete text suggestions you have for making that clearer?

What are the avenues for suggesting / proposing that the mitigations become normative?

We can continue to discuss them on this thread. I think if the implementers agree that a given mitigation should be standardized, then I expect we can add it. However, I would not expect that to happen in version 1.

@samuelweiler had suggestions / concerns about the current proposal and negotiating what
payment fields are shared (looks like the options argument would be a natural fit). Will that be
part of these changes?

I would not expect negotiation of which data is shared to be a version 1 feature of Payment Request API. That has not been part of the specification to date and I think we would need to have more discussion of real-world payment systems. Sam has opened a new issue where have started discussion:
#842

A related topic (outside of Payment Request API) involves device fingerprinting (through JavaScript and other mechanisms). Our ongoing discussions in the working group involve topics like how to manage user privacy preferences with demands for data from risk engines.

Ian

pes10k · 2019-03-04T20:55:51Z

@ianbjacobs

That was one of the suggestions from the call that made it into the pull request: to limit in the face of multiple calls with different parameters from the top-level browsing context. Are there concrete text suggestions you have for making that clearer?

I see the "For example, a user agent may restrict the number of successful calls that can be made based on the top-level browsing context" text. I'm not sure I understand the "successful calls" text there. Whats an "unsuccessful" call? If "unsuccessful" means canMakePayment returns false, then merely rate-limiting on "successful" calls won't do much to reduce its finger-print-ability. Apologies if I'm miss understanding but could you explain / clarify whats meant here?

A related topic (outside of Payment Request API) involves device fingerprinting (through JavaScript and other mechanisms). Our ongoing discussions in the working group involve topics like how to manage user privacy preferences with demands for data from risk engines.

Great! Where is the best place to stay up to date on these discussions?

ianbjacobs · 2019-03-05T02:03:39Z

Hi @snyderp,

I'll start by saying that this topic has been a challenging one for the Working Group, and new ideas are welcome. We are relying on implementaitons to help mitigate abuse while at the same time responding to merchant requirements to be able to decide what checkout experience they can provide that will afford the least friction.

The particular text that you are referring to no longer exists in my pull request. However, it may be that you have the same question over the new text.

I invite @marcoscaceres, @rsolomakhin, @danyao, and @aestes to weigh in on their implementation experience.

There have been other ideas on this topic that have not gained traction for other reasons; see #777 for example.

Regarding data gathering for risk analysis, that seems to lie partly within the scope of several W3C groups. The Web Payments WG has had some discussions with EMVCo about 3-D Secure, which gathers some data. We've also chatted with the Web Authentication Working Group about whether WebAuthn (e.g., attestations) might be helpful in reducing reliance on JavaScript. And FIDO and EMVCo are also discussing that topic.

To help facilitate some of these conversations we have been discussing the creation of a W3C Interest Group on Web payment security. A draft charter was reviewed by the W3C Membership, EMVCo Board, and FIDO Board; we are currently addressing feedback.

In short: I would like to make it easier to discover and participate in Web payment security topics. I hope this proposed IG can help fulfill that goal.

marcoscaceres

FWIW, rate limiting still feels ineffectual.

marcoscaceres · 2019-03-03T02:02:34Z

index.html

+          <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.

after reading the privacy minutes, I actually think this is an OK idea and npdoty questions was good.

Pros:

Website are likely to be calling this method more responsibly if there is a little UI indication to the users and only do so in the right page and time where users expect this to happen and checkout.

Cons:

Some users might freak out if they see such a UI notification or indication. there has to be a lot of carefulness and UX research from implementers side how to present this.

Why does it seem impractical?

I'm in favor of it too. Short of standardizing the mitigations (which would be better, but seems to be off the table), including the above seems like a second best option

marcoscaceres · 2019-03-04T05:41:34Z

index.html

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


Suggested change

<a>canMakePayment()</a>;

<a>canMakePayment()</a>.

marcoscaceres · 2019-03-04T05:42:40Z

index.html

+          </li>
+          <li>informing the user when <a>canMakePayment()</a> is called;
+          </li>
+          <li>rate-limiting the frequency of calls to <a>canMakePayment()</a>


Suggested change

<li>rate-limiting the frequency of calls to <a>canMakePayment()</a>

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

marcoscaceres · 2019-03-04T05:43:29Z

index.html

+          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);


Suggested change

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

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

marcoscaceres · 2019-03-04T05:45:39Z

index.html

+        <ul>
+          <li>the same effective top-level domain plus one (eTLD+1);
+          </li>
+          <li>the top-level browsing context;


Suggested change

<li>the top-level browsing context;

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

pes10k · 2019-03-05T04:58:16Z

@ianbjacobs

Thanks again for the reply. Sure enough, i was looking at the wrong text. Thanks for the clarification!

One other item related to mitigations, and one more reason you may want to include mitigation standardization in v1 (even if it slows things down): how does the user agent signal to the website "I am interested in using the Payment API, but I don't want to allow the fingerprinting risk implied by canMakePayment."?

Say the user agent is operating in this privacy-protecting state and takes some of the mitigation steps mentioned in the text, and turns canMakePayment off (e.g. "allowing the user to configure the user agent to turn off"). Is there some way the UA can say "ask me explicitly what I support, by sending me a form, or similar, but no passive techniques"? I dont see anyway to express this in the API as described.

Throwing SecurityError seems semantically wrong (there is no security related issue in this scenario). The NotAllowedError is only specified for the rate limit case. And in either case, the website might reasonably interpret the response to be "UA never allows using Web Payment API" or "i've been rate limited", instead of "UA doesn't allow the website to ask what payment methods are supported, passively." In which case, the canMakePayment functionality, as currently imagined might increase friction (since the site could assume Web Payments is disabled).

I suggest adding an additional exception type, or return value to the canMakePayment promise indicating "user is still interested in Web Payments, but no background / passive checking, to maximize use of Web Payments API. Thoughts?

marcoscaceres · 2019-03-05T05:10:25Z

I suggest adding an additional exception type, or return value to the canMakePayment promise indicating "user is still interested in Web Payments, but no background / passive checking, to maximize use of Web Payments API. Thoughts?

The use case remains that "can make payment?" is intended to be used to present, for example, an Google Pay specific button directly in the web page. Asking the user is not practical, because the site is effectively "port scanning" what supported payment methods are.

I think the only feasible solution here is for the user to have control over this (like Safari does). Basically, an opt-in this check:

"[ ] Tell sites I support "basic-card" (when not in Private Browsing mode)."

marcoscaceres · 2019-03-05T05:12:55Z

This is how Safari works:

pes10k · 2019-03-05T05:17:21Z

@marcoscaceres

I dont we're disagreeing. The correct answer is definitely to prompt, and to effectively not allow anything like how canMakePayment is designed. We discussed this on the PING call.

But, whether or not canMakePayment comes out or always leads to a prompt, or whatever else, i'm saying there needs to be more granularity in the reason the user is not returning accurate info on canMakePayment. That there needs to be a way to explicitly say to the site "i'm not going to tell you the payment methods I support passively, but I would still like to use the Web Payments API checkout flow."

marcoscaceres · 2019-03-05T05:20:03Z

That there needs to be a way to explicitly say to the site "i'm not going to tell you the payment methods I support passively, but I would still like to use the Web Payments API checkout flow."

heh, returns "maybe" :) But seriously, it's why in Firefox we always lie and just return true.

pes10k · 2019-03-05T06:10:40Z

@marcoscaceres that seems like a reasonable approach, but suggests it shouldn't be in the standard in the first place :)

Brave will very likely do something similar. Is anyone familiar with what Safari is planning on doing for non-Apple pay methods?

aestes · 2019-03-05T06:23:25Z

Is anyone familiar with what Safari is planning on doing for non-Apple pay methods?

Currently, Safari's only supported payment method is Apple Pay.

- Removed "alert the user" as an idea; deemed impractical

rsolomakhin · 2019-03-05T16:51:19Z

@snyderp wrote:

Whats an "unsuccessful" call?

Rejecting canMakePayment with NotAllowedError and a message Exceeded query quota.

pes10k · 2019-03-05T16:56:29Z

Currently, Safari's only supported payment method is Apple Pay.

Thanks! I should have asked differently though: Does anyone know who, other than Chrome, plans to implement the spec / canMakePayment as described in the document? Sounds like definitely not Firefox, definitely not Brave, and maybe not Apple?

rsolomakhin · 2019-03-05T17:01:02Z

@snyderp : Which part of the spec differs among the implementations?

From https://w3c.github.io/payment-request/#canmakepayment-method :

If the user agent has a payment handler that supports handling payment requests for identifier, resolve hasHandlerPromise with true and terminate this algorithm.

Firefox has a built-in payment handler for "basic-card", so they will always return "true". @marcoscaceres, correct me if I'm wrong. So Firefox implementation seems to match to spec, right?

ianbjacobs · 2019-03-05T17:02:08Z

Adding @romandev and @zouhir (and assuming @rsolomakhin and @danyao already watching).

Ian

rsolomakhin · 2019-03-05T17:04:57Z

@snyderp wrote:

I suggest adding an additional exception type, or return value to the canMakePayment promise indicating "user is still interested in Web Payments, but no background / passive checking, to maximize use of Web Payments API. Thoughts?

I like this idea. Our current behavior in this case is to return "false" in canMakePayment(), but a different error message would definitely be useful.

ianbjacobs · 2019-03-05T17:20:47Z

@snyderp and @rsolomakhin, would you support creating a new issue on the topic of finer-grain error reporting when canMakePayment() returns "false"?

Some observations (which I can carry over to a new issue as well).

An error message (e.g., "okToUseAPI") that indicates that the user does not want to share detailed information but would like to use the API under show() conditions would reveal some information about the user's browser configuration. For consideration: is that an improvement?
@rsolomakhin, you mentioned fine-grain error reporting for debugging. What are the other scenarios that you (or Google Pay) team would like to reflect in these messages?

Ian

rsolomakhin · 2019-03-05T17:29:20Z

@ianbjacobs : A separate issue sounds good. Does this need to go into the spec or best practices for implementers? I understand the error codes go into spec. Not sure about error messages.

Other scenarios that would benefit any payment handler or merchant:

Errors in SSL. For example, self-signed SSL causes Chrome to always return "false" to canMakePayment() and reject show() with "AbortError: Request cancelled."
Reasons why the payment sheet closed, e.g., "AbortError: User closed the payment handler", "AbortError: The payment handler cancelled the transaction", or "AbortError: User closed the card CVV entry form."

pes10k · 2019-03-06T03:59:20Z

@snyderp : Which part of the spec differs among the implementations?

@rsolomakhin I was basing what I said (that Firefox isn't implementing the spec as written) based on @marcoscaceres comment "But seriously, it's why in Firefox we always lie and just return true.". I take that to mean they don't follow the supportedNetworks part of the algorithm.

Brave will likely do the same (decision hasn't been 100% made yet) and return true no matter what, at least with "Shields Up".

about what data is shared, but rephrased to sound less like it has to be real-time

index.html

Co-Authored-By: ianbjacobs <[email protected]>

index.html

(Marcos and Ian edited.) Co-Authored-By: ianbjacobs <[email protected]>

Co-Authored-By: ianbjacobs <[email protected]>

index.html

Co-Authored-By: ianbjacobs <[email protected]>

index.html

Co-Authored-By: ianbjacobs <[email protected]>

aestes · 2019-03-14T23:53:42Z

This is how Safari works:

I should clarify something here. This option influences the return value of the canMakePaymentsWithActiveCard API in Apple Pay JS (and soon the hasEnrolledInstrument API in Payment Request).

When that option is unchecked (or the window is in Private Browsing), canMakePaymentsWithActiveCard will behave as if canMakePayments were called instead, returning true whenever Apple Pay is supported even if there are no enrolled instruments.

Neither this checkbox nor Private Browsing influence the result of canMakePayments in Apple Pay JS or canMakePayment in Payment Request.

ianbjacobs requested review from marcoscaceres, danyao and rsolomakhin March 1, 2019 20:36

rsolomakhin reviewed Mar 1, 2019

View reviewed changes

One S&P section is normative, the others are informative. Adjusted ma…

53a36e1

…rkup accordingly.

marcoscaceres requested changes Mar 5, 2019

View reviewed changes

- Editorial tweaks from Marcos

5943bb1

- Removed "alert the user" as an idea; deemed impractical

Added back canMakePayment() bullet about informing the user

a365dbe

about what data is shared, but rephrased to sound less like it has to be real-time

marcoscaceres reviewed Mar 12, 2019

View reviewed changes