Below is a snippet from our "Secure Deployment" guide, which is also good to know regarding MachineID. Further clarification will be added, since this could probably be described better. In essence, .getUniqueId() returns a unique identifier for the client that is tied to the runtime (Flash in IE vs Flash in Firefox vs AIR vs....). For each user account on the Windows machine, it will be different. For each different runtime, it will be a different ID. For each different browser, it will be a different ID. If the user uninstalls and reinstalls Flash, it will be a different ID. If the user were to go into the browser's Flash settings and de-authorize all licenses, the ID will change. In other words, the UUID returned by .getUniqueID will vary depending on which account and where the runtime is running from, and may change if the user uninstalls Flash or resets the license store.
However, if you use .getBytes() to persist the machineID somewhere, and then use machineID.matches(), that will instead disregard the runtime/account/browser/etc... being used and simply compare the hardware signature of the machine. This will always return you a TRUE if the machineID came from the same machine. The only drawback to this, though, is that if you have several machineIDs, you will have to compare the machineID with every existing machineID in order to determine if there is a match. If there is a large # of machineID, this computation can a long time to complete.
Depending on your particular use case, and tolerance for the limitations listed above you may choose to use .getUniqueID() (which is not as reliable as .matches()) or .matches() (which can take a long time to compare against all other MachineIDs, if there is a lot of existing MachineIDs to compare against)
////////////////////////////////
Tracking rollback and machine count when issuing licenses
If your implementation of Flash Access uses business rules that require the client to maintain state (for
example, the playback window interval), Adobe recommends that the server keep track of the rollback
counter.
The rollback counter is sent to the server in most requests from the client. If your implementation of
Flash Access does not require the rollback counter, it can be ignored. Otherwise, Adobe recommends that
the server store the random machine ID—obtained using
MachineToken.getMachineId().getUniqueId()—and the current counter value in a database.
If the business rules require that the number of machines for a user be tracked, the license server must
store the machine IDs associated with the user. The most robust way to track machine IDs is to store the
value returned by the MachineId.getBytes() method in a database. When a new request comes in,
compare the machine ID in the request against the known machine IDs using MachineId.matches().
MachineId.matches() performs a comparison of IDs to determine if they represent the same machine.
This comparison is only practical if there is a small number of machine IDs to compare against. For
example, if a user is allowed five machines within their domain, you can search the database for the
machine IDs associated with the user’s username and obtain a small set of data to compare against.
Note: This comparison is not practical for deployments allowing anonymous access. In such cases the
random machine ID can be used, however, this ID will not be the same if the user accesses content
from both Flash and Adobe AIR runtimes, and will not survive if the user reformats their hard drive.
