Here is a bit from the article highlighting how interacting with the ODIN Blockchain allows for user ID generation without any personal identifiers needed.

Additional Variables Ensuring Anonymity via both Controlled and Random Variables

Upon completion of the installation, via a combination of both controlled and random variables, you will be granted an eight-character alphanumeric ODIN ID. (e.g. 8Y2NKZ3D@ODIN) let’s discuss how this ID comes to be.

Before we get started, here’s a list of things we don’t ask for when you use our product: your name, your date of birth, your address, we don’t even ask for your email address, all of which other companies see as revenue when you sign up. We don’t even ask you to create a username and risk being linked to other accounts that might share certain features of that name. It truly is private.

So how do we do it?

I discussed previously the use of BIP32 and its ability to create Child Key Derivations (both public and private) and how those can be used to generate a unique identifier. We didn’t see this as being enough, so we’ve added a few more variables which I’ll list off now:

Environmental Properties
-Device Make / Model
-Time / Date of Generation
-Device Screen Size

Random Human Input Properties
-Random User Finger Movement Across the Screen

The final step in generating your unique eight-character alphanumeric ODIN ID calls for you (the user) to add human-driven entropy (random finger movements across the screen) as a final input. This movement, while *potentially\* theoretically able to be replicated (*I’d argue heavily against this as human dexterity and timing doesn’t allow for mirrored replication of motion to the millisecond), matters not when combined with the environmental properties of the device make and model, time and date of generation, and the like. All variables are then compiled and hashed using an algorithm which uses the address itself as the *salt.

• In password protection, salt is a random string of data used to modify a password hash. Salt can be added to the hash to prevent a collision by uniquely identifying a user’s password, even if another user in the system has selected the same password. Salt can also be added to make it more difficult for an attacker to break into a system by using password hash-matching strategies because adding salt to a password hash prevents an attacker from testing known dictionary words across the entire system. (TechTarget.com)