Trust signal for unregistered VIDs, simpler vendor names

What's new

• New trust signal: vendor ID isn't in USB-IF's published list. When a cable's e-marker reports a non-zero vendor ID that isn't in the bundled USB-IF March 2026 list, WhatCable now surfaces a trust card explaining that the number could be unassigned, copied, or assigned after the bundled list was generated. Wording stays hedged ("isn't proof of a problem, but on a clone cable it often appears alongside other inconsistencies"). None of the cable reports we've collected so far would false-positive on this — every one of them has a registered VID, including the chip-vendor VIDs that show up on Anker, Caldigit, Monoprice, Delock, etc.

  This is the third trust signal alongside the existing zero-VID and reserved-VDO-encoding flags.

• Vendor names now come straight from USB-IF. Previously the popover and cable reports ran every lookup through a small hand-curated map first ("Realtek" instead of "Realtek Semiconductor Corp.", etc.). The curated layer drifted over time and started shipping factually wrong attributions: 0x103C was labelled "HP" but USB-IF actually assigns it to AMX Corp, 0x0FFE was labelled "OWC" but is registered to ASKA Corporation, 0x152E was labelled "Lenovo" but is HLDS (Hitachi-LG Data Storage), and 0x0AF8 was labelled "Belkin" but is Taiwan Regular Electronics.

  All four wrong attributions are gone. Names you see now are USB-IF's published forms verbatim. Many will read slightly more verbose ("Anker Innovations Limited" rather than "Anker", "Logitech Inc." rather than "Logitech"), and that's intentional — they're accurate and not worth a maintenance layer that can drift.

Internal

• VendorDB keeps a curatedOverrides dictionary as a documented escape hatch, but it's empty by default. Add an entry only when USB-IF's name is genuinely wrong, mojibake'd, or unintelligible. Don't add overrides just to shorten verbose-but-accurate forms.