1649028 - Mastercard starting with 542418 detected as Diner's Club

Status: VERIFIED FIXED

(Toolkit :: Form Autofill, defect, P2)

Description

[Matthew N. [:MattN]]

STR:

1. Submit a credit card (CC) form with a 16-digit card number starting with 542418
2. Accept Firefox's offer to save it.
3. Open the list of saved cards in preferences

Expected result:

• MasterCard logo beside the card

Actual result:

• DIner's Club logo beside the card

The IIN 542418 matches:

{ type: "diners", start: 54, end: 55, length: 16 },

https://searchfox.org/mozilla-central/rev/21f2b48e01f2e14a94e8d39a665b56fcc08ecbdb/toolkit/modules/CreditCard.jsm#41

I believe bug 1647043 used Wikipedia as a source of truth for card type detection but my understanding is that it's very incomplete and therefore we decided against it in 2018 and were looking at buying access to one of the various databases for these. What changed that made us think that Wikipedia was now sufficient? For the original CC autofill MVP we also left saving/filling of cc-type out of the scope since many website can automatically detect it and we didn't have accurate data for doing detection ourselves. IMO it's worse to give incorrect data than to require the user to choose this themselves. Eventually they will submit a form where we would be able to capture this information and (silently) update our storage.

Example of databases that have the correct network:

• https://lookup.binlist.net/542418
• https://www.binbase.com/search.html
• https://www.bindb.com/bin-database.html

Comment 1

[Zibi Braniecki [:zbraniecki][:gandalf]]

I believe bug 1647043 used Wikipedia as a source of truth for card type detection but my understanding is that it's very incomplete and therefore we decided against it in 2018 and were looking at buying access to one of the various databases for these.

Do you have an evaluation of how incomplete it is? If it's just missing several ranges, we can improve our db and improve Wikipedia.

For the original CC autofill MVP we also left saving/filling of cc-type out of the scope since many website can automatically detect it and we didn't have accurate data for doing detection ourselves.

A number of high profile websites that we tested against used the type field.

IMO it's worse to give incorrect data than to require the user to choose this themselves.

Agree, and I think understanding the scope of the problem is important to evaluate how far off we are.

Do you have any suggestion on how to evaluate how many cards we'd get wrong with the current ranges and how hard would be to increase it beyond, say 99%?
Maybe we could also reduce some ranges to leave more numbers as undetected and only detect the most common (Amex, Visa, MasterCard?) and "clean" ranges.

Comment 2

[Jim Mathies [:jimm]]

needs a priority.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1647043

Comment 4

[Matthew N. [:MattN]]

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #1)

I believe bug 1647043 used Wikipedia as a source of truth for card type detection but my understanding is that it's very incomplete and therefore we decided against it in 2018 and were looking at buying access to one of the various databases for these.

Do you have an evaluation of how incomplete it is? If it's just missing several ranges, we can improve our db and improve Wikipedia.

No, but you can compare your ranges to data in online databases. If companies are selling their databases for over $1,000/year I doubt that Wikipedia's table is comparable.

https://github.com/braintree/credit-card-type/blob/master/lib/card-types.js seems to have different data under an MIT license.

For the original CC autofill MVP we also left saving/filling of cc-type out of the scope since many website can automatically detect it and we didn't have accurate data for doing detection ourselves.

A number of high profile websites that we tested against used the type field.

The number of sites that require types isn't relevant since we can both save and fill from the same type fields. See what I said: "Eventually they will submit a form where we would be able to capture this information and (silently) update our storage.".

IMO it's worse to give incorrect data than to require the user to choose this themselves.

Agree, and I think understanding the scope of the problem is important to evaluate how far off we are.

Do you have any suggestion on how to evaluate how many cards we'd get wrong with the current ranges and how hard would be to increase it beyond, say 99%?

You can probably evaluate using https://github.com/binlist/data/blob/master/ranges.csv which is ~2% of binlist.net's data if you make some assumptions.

Maybe we could also reduce some ranges to leave more numbers as undetected and only detect the most common (Amex, Visa, MasterCard?) and "clean" ranges.

Sure, if we can determine what those are.

IMO we should back out the regressing patch in the meantime. I'm also removing the polish keyword since incorrect data (and branding) isn't a polish issue.

Comment 5

[Zibi Braniecki [:zbraniecki][:gandalf]]

IMO we should back out the regressing patch in the meantime. I'm also removing the polish keyword since incorrect data (and branding) isn't a polish issue.

My understanding is that our logic of determining the card type comes into play only if the user saves a card from a form that doesn't use the type field, and then uses it in a form that does.

That's a rare case I believe, and even when it happens, the worst scenario is that the website will reject the form because the card type doesn't match their database. In such case, the website will flag the type field as error and the user can just select the right card, send and we'll show the "update" doorhanger.

If I'm correct that our current ranges work for vast majority of card numbers (say, 90-95%) and end up being noticable for a small minority of users in the scenario listed above, and the worst case is that they need to correct the type in the form, I don't think it's a regression warranting a backout.

Can you explain further why you think otherwise?

Comment 6

[Matthew N. [:MattN]]

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #5)

IMO we should back out the regressing patch in the meantime. I'm also removing the polish keyword since incorrect data (and branding) isn't a polish issue.

My understanding is that our logic of determining the card type comes into play only if the user saves a card from a form that doesn't use the type field, and then uses it in a form that does.

That's incorrect as the wrong network is displayed in autocomplete and the management UI irregardless of which future form is used for filling.

That's a rare case I believe, and even when it happens

If you think it's a rare case that the card network needs to be specified then the loss of automatically determining the card network is also low. That's why saving/filling cc-type was out of scope for the CC 2017 MVP.

If I'm correct that our current ranges work for vast majority of card numbers (say, 90-95%) and end up being noticable for a small minority of users in the scenario listed above, and the worst case is that they need to correct the type in the form, I don't think it's a regression warranting a backout.

Did you measure that 90-95% using the data I linked to? The card that this bug is about is/was the #1 recommended card in the US for many years (Citi Double Cash) so I estimate it affects millions of cards (Citibank has 67.8M cards in circulation, you can even see an example of an affected card on that page for Citi Platinum Select so this problem isn't limited to Double Cash)

Can you explain further why you think otherwise?

There is low benefit to users while introducing a somewhat embarrassing user-facing regression for millions of cards. I've never seen the wrong card network automatically chosen in my whole life, that's what makes it somewhat embarrassing… people don't expect this to be wrong ever.

Comment 7

[Zibi Braniecki [:zbraniecki][:gandalf]]

Thanks Matt! I think based on what you said we should re-triage.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:MattN, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 9

[Jim Mathies [:jimm]]

We're going to collect telemetry first on how often the user changes the type of card after we autofill.

Comment 10

[Jim Mathies [:jimm]]

Bug 1653672 - Telemetry - Record when a user changes a card type after the card type is prepopulated

Comment 11

[Mathew Hodson]

Wikipedia (https://en.wikipedia.org/wiki/Payment_card_number) says that the 54-55 range are Mastercard co-branded.

Deleting this line would fix the card in this bug:
https://searchfox.org/mozilla-central/rev/21f2b48e01f2e14a94e8d39a665b56fcc08ecbdb/toolkit/modules/CreditCard.jsm#41

All those cards would then be detected as Mastercard, which is correct from Wikipedia, and match this line:
https://searchfox.org/mozilla-central/rev/21f2b48e01f2e14a94e8d39a665b56fcc08ecbdb/toolkit/modules/CreditCard.jsm#49

Comment 12

[Zibi Braniecki [:zbraniecki][:gandalf]]

While I agree we should gather more telemetry, fixing this particular bug seems easy, as Mathew indicated in comment 11.

Let's do this.

Comment 13

[Zibi Braniecki [:zbraniecki][:gandalf]]

Attachment: Bug 1649028 - Mastercard starting with 542418 detected as Diner's Club. r?mattn

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0bb5d4fadd6d
Mastercard starting with 542418 detected as Diner's Club. r=abr

Comment 15

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/0bb5d4fadd6d

Comment 16

[Alin Ilea, Desktop Test Engineering]

Reproduced the initial issue using an old Nightly build 80.0a1 (2020-07-21) and card number: 5555555555554444. The Diners Club card logo is displayed.
Verified - Fixed in latest Nightly 80.0a1 (build id: 20200724093206) using Windows 10 and Ubuntu 18.04. The Mastercard logo is displayed accordingly using the same card number.