Leave Off Unneeded Information

[adamroach]

This is a recommendation from the Security and Privacy Checklist review. See https://docs.google.com/document/d/1w7ginyzNg-xZUmITK4vzcGUKB4gbMOAvlkWWaRtX14k/edit?usp=sharing for additional detail

The Basic Card Payment specification provides additional information that forms a unique correlator. Unlike unique, cross-origin information provided by the Payment Request API, the cardNumber field provided by the Basic Card API is (necessarily) required rather than optional. The current document appears to assume that any Basic Card Payment app will request all possible fields; however, there is a PR filed for leaving off unneeded information. For the sake of privacy, we recommend this PR be accepted.

[mattsaxon]

The PR that @adamroach mentions was closed after discussion at the Sept 2016 F2F, pending a potential reopen. With Nick Doty's email to the group this morning, it is worth considering if we should once again look at this issue prior to moving to CR.

Options;

1. Add fields filter to Basic-Card
2. Add fields filter to Payment-Request (so it can apply to all PMIs)
3. Defer till a later version

[adrianhopebailie]

@mattsaxon For clarity, are you suggesting that the merchant website be able to specify which fields are mandatory and which optional in the payment response for a basic-card payment?

i.e. A merchant website can say "I support basic card but I only want you to return the PAN and expiry"?

[mattsaxon]

@adrianhopebailey, that's correct

[adrianhopebailie]

Is the privacy implication here that the merchant doesn't want to see the name on the card?

[ianbjacobs]

My recollection from previous discussions is that about friction collecting information (which may lead to dropoff). Matt cited CVV as one example. ("I don't want you to prompt for CVV; I accept the risk.")

However, it is not clear to me that shipping implementations allow for collection of less than the five fields.

Ian

[marcoscaceres]

Apart from cardNumber, the spec makes members optional... if the user chooses not to include some member's details, then they are just set to the empty string.

However, certain user agents force the user to enter all credit card information before they can proceed... but all user agents allow the user to abort the payment process.

Now, just the first 6 digits of the card number can reveal about a user (using https://www.bindb.com):

• Card Brand:
• Issuing Bank:
• Card Type:
• Card Level:
• Iso Country Name:
• Iso Country A2:
• Iso Country A3:
• Iso Country Number:
• Bank's website:
• Customer Care Line:
• Bank Address:
• Formal Bank:
• Commercial/Personal Card:
• Additional Info:

@adamroach, do you think we should make some kind of mention of the above?

[mnoorenberghe]

What's clear to me is that my complete billing address (including phone number) shouldn't be sent to every merchant using basic-card since most checkout web forms using credit cards don't require all that information now and so users won't expect the information to be leaked. It seems like Apple has a similar viewpoint since their Apple Pay payment method doesn't include the billing address by default, the merchant needs to specifically request an array of requiredBillingContactFields. I personally don't think Mozilla should ship an implementation of basic-card that leaks the billing address by default.

Even if the merchant indicates they require a postal billing address, it's not clear whether a billing phone number is required even though that is also part of the PaymentAddress structure. It seems like we should have a separate option to request the billing phone number. e.g. if we copy Apple's approach we could have

requiredBillingContactFields: [
  "name",
  "phone",
  "postalAddress",
]

(values are a subset of ApplePayContactField options)

I would ideally like the address to be even more fine-grained since some merchants only need the ZIP code for fraud detection, not the rest of the address.

Btw. I don't think an exclusion approach (#29) is the right idea as the defaults will heavily influence what developers request and we should only be giving the minimum required by default.

[marcoscaceres]

Proposal is to have certain fields excluded for privacy reasons. Then, we can add something like requiredBillingContactFields if we need it.

[stpeter]

As I noted in IRC during the F2F, our user research at Mozilla indicates that users are quite leery about exposing more sensitive information like their phone number. If they know the phone number is needed for shipping purposes they're more accepting. Gathering this data (or exposing data that's really not required) will legitimately raise privacy concerns among a broad swath of users - especially these days. Furthermore, there's no method by which the merchant can specify why any given field is being requested (e.g., "we need your phone number to contact you if there are any problems with delivery"). For some users, being asked for phone number without a legitimate or putative need might be a cause of shopping cart abandonment. This too would be worth researching with users.

[ianbjacobs]

My takeaway from discussion in Singapore [1] is that there was some support default behavior of not returning phone information.

[1] https://www.w3.org/2018/04/19-wpwg-minutes.html#card5

[marcoscaceres]

Now part of #52

[mnoorenberghe]

@marcoscaceres I don't think this issue should be closed after only leaving off the phone number as that doesn't fully address the privacy/security review and the concerns raised in the thread. Other fields mentioned above that may not be necessary:

• CVV
• Zip/Postal code
• mailing address other than the Zip/Postal code for verification (I assume the recipient/name would be needed together with the address)

I think requiredBillingContactFields (with somewhere for CVV to be called out too, in the same renamed or different property) would be wanted. If we can't have that then merchants are going to end up getting more info than they need and currently collect via <form>s and that will likely be bad for merchants (more obstacles to check out; handling unwanted data) and buyers (more data to fill out; questions about merchant need for such data and therefore abandonment).

[marcoscaceres]

Happy to revisit. At the f2f, we only agreed to remove phone number.

[marcoscaceres]

Just a note... we can discuss further here to understand the scope of the problem, but the above looks like it should spin off into multiple (related) bugs.

[marcoscaceres]

@ianbjacobs, do we have an authority in the WG on credit card fraud detection that can definitively tell us exactly which parts of the billing address are pertinent to fraud detection? I want to make sure @mnoorenberghe's concerns are addressed, specially if we can drop more fields from billingAddress.

[marcoscaceres]

Wikipedia has some info:

• https://en.wikipedia.org/wiki/Address_Verification_System

[marcoscaceres]

Also, is AVS the only reason for billingAddress?

Ok, The You Tubes tells me that cardholder name doesn't participate in AVS. So that's a potential target for removal.

[marcoscaceres]

So, some options here:

• On "payment method change": billingAddress redacts "organization", "phone", "recipient", "addressLine" and can chop post code.
• On "user accepts payment": billingAddress redacts "organization", "phone", "recipient", and can chop post code. The "addressLine" stays tho, because that is matched by AVS.

[mnoorenberghe]

That sounds good for when the merchant opts in to getting a billing address.
IMO the default should be a null billingAddress for both algorithms and if the merchant uses AVS they can opt-in to it.

[marcoscaceres]

IMO the default should be a null billingAddress for both algorithms and if the merchant uses AVS they can opt-in to it.

Agree 💯. AVS is only used in 3 countries, so why we should pass billing address by default doesn't make much sense.

[marcoscaceres]

Ok, I've updated #65 so it's always null, unless it's explicitly asked for.

From what @zkoch said previously, it might be too late for Chrome to roll this back. So we might need to make a concession and say that in certain regions the billingAddress MAY be added by default.

[marcoscaceres]

Ok, also made it optional for the user agent to add the billing address in, say, the US, UK, and Canada...

[ianbjacobs]

Hi @marcoscaceres,

I changed the title back to the original title. The original use case from @mattsaxon was for the merchant to say to the browser (or other payment handler): don't collect the CVV; I would rather the user have less friction and I accept the increased risk.

One proposal had been that each payment method might support an array in request data where the merchant could specify which response fields to exclude when building the response.

Since the original use case ("don't collect CVV due to friction") other use cases have arisen:

• The user doesn't want to share information for privacy reasons.
• The merchant doesn't want to collect information for liability reasons.

I would prefer that this issue remain merchant-focused (rather than user-focused). The original issue is that the merchant wants to indicate which payment method response fields it wants the payment handler to exclude.

Ian