With mobile usage now far outpacing desktop usage, the latter has an antiquated air about it to many. Mobile is the future, implying that desktop must be the past. It’s natural to expect a more secure future, having learned from past failures. Indeed, as noted in the preceding piece, mobile devices feature no shortage of security controls.
However, mobile devices are also new enough that we are still engineering around the problems they introduced. Although cellular networks are decades old, their infrastructure still lacks a means of concealing device locations or encrypting messages and calls. Cell-site simulators exploit these very limitations.
Developers and security researchers continue to find new inferences that can be made about users by correlating the readings from the panoply of mobile device sensors — to say nothing of sensors on internet of things (IoT) devices, some of which can be thought of as “mobile.”
By contrast, desktop devices are well-understood architecturally. Their operating systems are decades old, maintained by the most experienced developers in the industry. As such, secure engineering patterns are established and validated, a practice that has only recently taken shape in mobile OS development.
In this second installment of my juxtaposition of “security” and “privacy,” we will examine the unique challenges and opportunities for engineering these properties on desktop platforms.
Desktop Hardware Privacy Advantages
A claim that desktops are less secure than mobile devices can be true or false, but this depends highly on their configuration. While desktop devices are less secure out of the box, they are more private and can be made more secure than mobile devices.
For one thing, users can impose more hardware restrictions on desktop devices because their components are easier to access physically. With mobile devices, the hardware is so tightly packed into a glue-sealed brick that, unless you really know what you’re doing, you have to just trust the OS when it says an application was denied hardware access. Mobile devices also house many more types of sensors.
With desktops and even some laptops, users can install physical switches that disconnect hardware units on demand. A simpler option is to remove all but the essential built-in hardware and only use external accessories, such as USB-connected webcams, microphones, and keyboards.
Sandboxing and Isolation on Desktops vs. Mobile
Sandboxes are a key element of mobile security design. In the case of Android and iOS, this is implemented via kernel-level user permission boundary controls. This is a sound approach that builds upon well-tested OS design principles, rather than reinventing the wheel. However, this is just one layer of defense, only as strong as the kernel itself. Applications are just one kernel exploit away from breaking out of their boundaries. They aren’t common, but they do exist.
With desktop OSes, there is a broader selection of sandboxing techniques that are interoperable. Implementations vary in terms of resource utilization and rigidity of the sandbox boundaries. The simplest approach is BSD jails, which have been around for decades. Similar implementations are available in other Unix and Unix-like systems. A step up from there are all the same kernel permission boundaries that mobile sandboxing consists of.
If you need the most rigid possible boundary, you can run applications in a virtual machine. These are tiny software-emulated computers, complete with their own operating systems. Apps running in them can’t tell there is another OS outside the one they’re in. You can’t compromise a system you don’t know about, can you? This is considered the gold standard of application isolation and is utilized in some of the most sensitive security environments in the world. The security-focused Qubes OS Linux distribution, for example, transparently virtualizes every application.
As stated previously, mobile OSes do not grant you root access under any circumstances. Without root, you have limited means of deactivating or circumventing anything that collects your data without your consent. On desktops, you can use root to shut down any rogue processes and block outside access to files, among many countermeasures. It’s only with root privileges that you can even detect everything that’s going on. With one command, a Linux user can see every single open network connection, where it’s going, and what files each one is accessing. There is no comparable alternative for any mobile OS.
Cell-connected devices put the privacy-minded user at an additional disadvantage that root access would otherwise spare them. Architecturally, the SIM and the baseband are able to override anything else that happens on a mobile device. This was designed to prevent users from thwarting the billing for network use. However, the implementation of these controls leaves the door open to abuse. Anything that can crack the SIM or the baseband has free rein over the device. Without root, users can’t do anything to stop that.
Open the Source, Close the Gates
Desktop OSes have one last trick up their sleeve: compilation from source. Mobile OSes, and the private companies that develop them, typically profit from limiting software installation to app stores. Certainly, they prevent the user from installing opaque software from questionable sources, but the app stores aren’t as safe as they are made out to be. With millions of apps each, there is no way Apple or Google can review them all.
However, by compiling open-source software, which is far easier on a desktop, you are installing software that anyone can review and that your computer built from scratch. You don’t have to trust whoever bundled and distributed an application binary package. The assurance of exactly what code is running on one’s device is the single best privacy protection a user can enjoy. Imagine how tricky it would be to eat healthy without nutrition labels. Privacy without open-source software is no less daunting.
The Fork in the Code
Although this and the foregoing article applied strict definitions of “privacy” and “security” to operating systems and, to an extent, the hardware they run on, they can be used to understand any technology. These terms can just as easily characterize individual applications or entire networks. They can even apply to the analog world. They are merely lenses for viewing groupings of properties.
To me, while abstract consideration of systems can be instructive, I favor practical applications for real-world outcomes. So, where do we users come into the picture? Simply put, you have to decide your own preferred balance of security, privacy, and effort. Security, and much more so privacy, come at a cost of effort. The first step is knowing what that effort actually gets you. Good luck on the many steps to come.
