The customization_id in VPD was introduced to solve signing problem for LOEM projects, in format OEM[-VARIANT]. It worked fine for real LOEM projects at that time, but it's then incorrectly used by Zerg projects to identify hardware difference, and becomes a mess when we are seeing more Zerg+LOEM model projects, since it then needs to share and check ID between OEMs, so the OEM name field must be obfuscated - and in the end it becomes something like PARTNERNAME-GOOGLENAME on few projects.

In original design, customization_id was reserved for firmware signing, and signing team wants to share same key for same OEM. It's also used for OOBE customization that devices use it to look up initial wallpaper and apps.

When reviewed for newer devices like Coral today, we realize:

1. hardware difference need to described by a hardware strap difference. This is moved to called "chassis id", provided by mosys.

2. OEM does not need to share signing key now, and with the help of unified build, firmware updater should change to find firmware image and keys using "model" name.

3. In order to prevent information leak, we should not use OEM name no matter how. This implies retrieval of customization should also base on model name.

So we should stop provisioning customization_id and replace that by either chassis id (for scripts that wants to know hw difference) or model (for features that needs to know the difference combining hw & sw, especially OEM).

To speed up the migration, we currently set a special logic in mosys to resolve customization: first VPD "customization" then per platform callback then model.

This issue is created to track that we should migrate legacy devices as well so we can remove the special hacks in mosys customization command.