More bad design decisions

Amazon was a bookstore. ASINs started out as ISBNs, and indeed ISBNs are still the identifiers for books. When they started shipping non-book items, they added ASINs starting with a B to de-conflict with ISBNs which are numeric (plus maybe a terminal X as the check-digit)

Numbers on the product starting with an X are fulfillment IDs. They're for tracking items as they pass through the warehouses. There's no public way to convert them back to the ASIN.

LPN prefixes are for returned items that typically show up on Amazon Resale.

None of these are for humans, they're for automated systems. Staff are not typing them, there's a barcode for them to scan instead. You should never need to read one over the phone.

Theo

Well, it was probably at some point considered normal to read ISBNs over the phone for custom orders, before the internet took over as a communi- cation medium.

Of course, not at Amazon.

Best wishes, and happy book orders!

The phone gripe related to "confirmation codes" from IVR systems. Identifiers that are conveyed by spoken word.

But, the potential ambiguity extends to amazon identifiers, CoAs, service tags, etc. There is no one constraining these people to use certain sets of characters; they are free to choose any subset or alternative form that *seems* appropriate.

To someone who thinks about how they are LIKELY going to be used.

By the entities that are likely to use them.

Obviously, they expect humans to be part of that class as they don't simply display barcodes for item identifiers!

You may need (want!) to type one in that you had previously recorded on a slip of paper. Note that Amazon deliberately recognizes such identifiers as search criteria so they have obviously anticipated this usage else they could have simply returned "item not found".

Ditto eBay (though their identifiers are purely numeric).

While I can differentiate *my* 'B' from *my* '8', and my 'O' from my '0', and a '1' from an 'L' (always written in uppercase for obvious reasons), seeing the difference on the screen isn't always that obvious.

The answer is: "It's complicated." Security and collision avoidance are the big considerations.

No, it isn't. You can choose any scheme for creating an identifier with the goal of ensuring the user can't FABRICATE one that coincides with the one that you would *issue* (otherwise, the user could claim to have performed an action and used the "unguessable" identifier as proof of that.)

We protect financial accounts with 4 digit PINs yet want to ensure a customer can't fraudulently claim that he paid a $30 invoice by guarding it with an 8 digit alphanumeric?

More like lazy thinking on the part of the folks who concocted the scheme (witness the fact that some similar vendors can achieve the same sense of "security" with just a 4 digit confirmation number)

I had to implement a "passcode" for a user identification scheme where many of the users were developmentally disabled. The goal was to provide an audit trail for their actions. And, ensure the recorded actions were truly their and not those of someone who was acting as them.

They had a physical token to present as an identifier -- confirmed with a "secret" passcode. The passcode was a set (unordered) of 2 selections from a group of 12 items (~100 combinations). As a numeric identifier would be difficult for them to remember, the menu of items was:

- dog

- cat

- elephant

- giraffe

- zebra

- mouse

- snake

- monkey/ape

- dolphin

- flamingo

- crocodile/alligator

- panda/bear These were illustrated pictorially on a touch screen as large tiles.

Note that each is deliberately chosen to be unambiguous (I don't put a lynx in the list as that could be seen as a cat; no horse as that would be a stripeless zebra; a tiger could be a cat or zebra; etc.) with a considerably imaginative "Hamming distance" between choices -- size, shape, coloring, etc. (is the user noticing the stripes on the zebra? or, its horse-like shape? the long neck of the giraffe? is the flamingo seen as a bird? or, something PINK? Or, something with really long LEGS?? etc.)

Surely, displaying a keypad would be more expedient (for the DEVELOPER!). "Was my code 1428 or 1842? Or, maybe 2814?" "I've forgotten my code. Can you help me set up a new one?" etc.

We're not trying to create a system used to authorize the deployment of munitions. Rather, to ensure a misplaced "id card" isn't used by someone "unauthorized" and those actions seen as FAULTS by the original card holder. ("Bob has been making a lot of mistakes. Perhaps we shouldn't let him continue to have this responsibility?")