Let's first ask ourselves how such circumstances could have occurred. I know for sure that if my OS had tracking software built into it, I wouldn't use that OS. I would use and preserve alternate options (like the open-source Ubuntu). So if all devices use the same OS, and everyone is fine with it, then people like me would have to be satisfied that it's privacy-conscious. (Or we have no choice, but that's not the scenario this answer is working in.)
Since this is a long answer, containing a bit of real-world background information on how certain steps are accomplished, this answer is split into sections.
- Introduction elaborates on the answer itself for the purpose of readability, and gives some justification as to this answer.
- The Operating System restates the properties of the operating system, and also reiterates the question: "How to avoid data tracking".
- How to Keep My Privacy While My Data is On Someone Else's Computer(s) describes how I can keep my personal data secure while it is stored somewhere publicly accessible, through use of encryption. It also introduces the concept of the encryption key, which is utilized throughout this answer
- How to Store My Data describes two methods of how the OS might store my encrypted personal data where it would be accessible from any device, as well as the downsides to one method. It also provides hints as to how the other method would work.
- How To Prove That I Know the Key describes a method to verify that I know the encryption key (as introduced in section 3 "the section with the obnoxiously-long title").
- How This System Would Work describes the back-and-forth between the client and server to obtain my personal information (given that the client knows my password).
- Vulnerabilities points out two key vulnerabilities of the client, as well as how these vulnerabilities can be mitigated. It also notes that one of these vulnerabilities still is problematic.
- This Answer is Incomplete describes in what way this answer fails to completely fulfill the requirement (remote biometric authentication doesn't seem to be a solved problem)
- Conclusion wraps up this answer, and summaries this answer, so that this answer is a proper essay that first tells you what it's about to tell you, tells you the thing, then tells you what it told you.
The Operating System
Let's consider the properties of the operating system you've described:
- Each user has a universally unique user account.
- User accounts can be accessed using the password, or by biometrics.
- Each user account has associated data accessible from every hardware device.
Given these three properties, you want to prevent data tracking.
My answer is this: these three properties do not necessarily mean that the OS needs to do things leading to.
How to Keep My Privacy While My Data is On Someone Else's Computer(s)
First, let's talk about encryption. If all of the personal data that leaves my computer is encrypted with a proper encryption method (such as AES with a 256 bit key), then it will be nearly impossible for my data to be read. The hardest problem is remembering this key. Of course, I already have a piece of unique secret information: my password!
However, a password is usually a piece of very structured data (good passwords from password managers are not, but they aren't easy for me to remember). This makes it unsuited as as an encryption key. However, there's a technique called "key stretching" which would transform the password into something more suitable as a key. Here's how it works:
I take a cryptographic hash function (let's say, SHA256, or "SHA" for short) and apply it to my password. That would make my password
SHA(password). This would be good, except for one thing: everyone who uses, for example, "password1", as their password would have the same encryption key, and so they would be able to access the data.
To combat this problem, we'll introduce the concept of a cryptographic salt. This is a few dozen random characters that are attached to my account. If I run SHA on the password combined with the salt, I'll get a key that would be more unique. It would be
SHA(password + salt) rather than
As an example, if my password was
"password1", and the salt of my account was
"dQw4w9WgXcQ", then my cryptographic key would be
With this key, I can encrypt my user data, and feel safe that unless someone knows both my password and my salt, they won't be able to read my user data even if they had all of it.
How to Store My Data
Now that I have my encrypted personal data, I need a way to store it so that I can get it from any computer. There's two ways we might accomplish this for the OS:
- We can store all the data on one big computer.
- We can store a little bit of the data on lots of small computers.
There's multiple reasons to favor one option above the other. Storing all the data on one big computer has the advantage of simplicity. It's really easy to wrap your head around this. However, it comes with some downsides. For example, if the big computer (aka. the "server") breaks, then we either have to hope we have a backup, or everyone's personal data is completely gone. Or, if the owner of the server decides to hold your data for ransom, they can do so.
However, either option will fulfill the requirement that I can access all my user information from any device. So, while I might not elaborate on how it would be possible to store my data by putting a little bit of it on lots of small computers (or "a peer-to-peer network"), rest assured that it is possible. (Note: this is how torrenting works.)
How To Prove That I Know the Key
My account, on top of having a salt and user data, has two additional pieces of privileged data: a public and private key pair. The private key, of course, is encrypted behind my encryption key. The public key, being public, is accessible to the public.
So, I have four pieces of user data:
- My salt, which is public,
- My public key, which is public
- My private key, which is encrypted, and
- My user data, which is encrypted separately from my private key.
If I encrypt something using my private key, it can be decrypted by the public key. This may not seem useful, since everyone theoretically might have my public key. However, I could have only encrypted the message if I had the private key. So, if someone who knows my public key sends me a random number, I can encrypt it using my private key and send it back to them. They would then be able to decrypt it, and verify that I have the private key.
But private keys have very specific properties, and so I can't just get a random 256-bit number and call it a private key. And how does having the correct private key prove that I have the encryption key, anyways?
The solution is that if everyone knows what my private key looks like when encrypted, they can send it to me, and I can decrypt it, and use it to sign a random number. They verify the signed random number. Thus, they know that I knew the private key. Since the private key is not known except for the encrypted version, that also proves I could decrypt the private key (or the private key is known to me, which is a more secure state than using passwords to protect my data), and thus that I have the encryption key.
This was a bit complicated, so we'll just call the entire procedure "verifying my identity", and if you didn't understand or read the procedure, you can take it on faith that it works.
How This System Would Work
The "me and my computer" system is called the "client". For simplicity, we'll call the place that stores all my data the "server", even if it's a peer-to-peer network.
- The client requests login info for a username
- The server sends me the account's salt, encrypted private key, and a random string of characters.
- The client computes my encryption key using the salt and the password I entered.
- The client verifies my identity.
- The server sends me my personal information.
- The client decrypts this information.
And now I have my data accessible on any device, but only if I know my password.
There are two major vulnerabilities of this method. First, if your password is easily guessable, then someone could guess it and gain access to all your personal data. This is solved with modern techniques: either have a really random password, or use a password manager. The second is more insidious:
An attacker could create a device that looks like it has the OS loaded on it, but it secretly reports my username and password to the attacker when I use it. This is similar to a web attack where a website is made to be completely identical to the genuine website, and has a URL like "google.com-[something].com" in hopes of someone logging in to steal their passwords. However, unlike that attack, this vulnerability can't be detected by reading the URL of the webpage.
Unfortunately, I can't give a good solution to this second vulnerability (perhaps some sort of "makers' mark", or an anti-counterfeiting mark on genuine devices which cannot have the OS modified might work, but they aren't good solutions, and seem like they might be easily bypassed).
This Answer is Incomplete
This system as described doesn't really have the ability to use biometrics to sign in. If you're alright with that, then that's fine. Biometrics are really insecure, anyways.
But if the feel of the setting really requires biometrics, then a RFID implant might fit the feel just as well or perhaps better, while still maintaining security.
First, I began with a reading of the question as "How can a universal OS with certain specific characteristics prevent data tracking above and beyond what we already have today?" rather than the more prevalent "How can I fool a universal OS to prevent data tracking if the OS itself is doing data tracking?"
Second, I introduced essential concepts, and outlined how an OS could be designed.
Third, I pointed out two key flaws in this design, and highlighted where this answer does not completely cover the question.
Fourth, I explained how to mitigate one of the key flaws, and how to make an analogous replacement, changing "biometric authentication" to "RFID-based authentication" for the purpose of maintaining the feel of the setting.