Just yesterday a paper (partly) on Qubes was published. Find the integral publication here, which I highly recommend reading for full context. Bellow I transcribe some of the Qubes-relevant portions (thanks to the CC-SA-BY license) - all credit goes to the original authors.
Qubes: towards a secure desktop ecosystem
Qubes (qubes-os.org) is an OS structured around the idea of allowing users to create an almost unlimited amount of discrete “safe” spaces from which to conduct their digital life.6 With a system architecture optimized around providing such spaces, the project seeks to address what Qubes developers identify as a crucial problem plaguing contemporary computing systems—namely that matters of digital security are seen as an “add-on” or left as an afterthought in the development of technical infrastructure. By breaking computing into smaller discreet pieces, Qubes tries to re-envision how an OS looks and works. As explained by a user interviewed for this study, Qubes empowers its users to “create spaces for yourself […] where you feel physically comfortable and can undress from the armor. You don’t need to be on the watch all of the time” (Interview #11).
In development since 2009, the founder, Polish computer scientist Joanna Rutkowska, envisioned a system which would contain the many different kinds of attacks that can occur when users connect their computers to a network amid a rapidly evolving “threat landscape” of targeted surveillance and intrusion. Started as a personal project, Qubes has attracted a small paid team and a community of volunteers and users, raising hopes for a new kind of computing experience free from hyper-vigilance (see Harvey et al., 2012).
How does Qubes work? Upon first “logging in” to the OS, the user accesses a standard desktop window. A little “Q” icon on the menu selector gives her access to a list of self-contained “virtual machines” which function as separate, secure spaces within a larger computing environment. Some virtual machines are designated as “disposable”—meant to only be used once for tasks deemed particularly sensitive—while others are “persistent”—meant to be used again and again. Some of these virtual machines come set up as ready-to-use templates, while others require an elaborate process of customization. The user models her digital presence across these separate compartments to make her experience more resilient to surveillance.
These functions add up to what can be understood as a counter-imaginary of compartmentalization. Rather than trying to “patch every single known security bug” in commercial OSs (Rutkowska and Wojtczuk, 2010: 5), Qubes seeks to limit the damage of potential attacks by re-organizing the OS architecture, with the goal of “not preventing exploitation but containing it, to minimize the problem” (Interview #2). It is important to note that compartmentalization is not “new” for human rights defenders or allied technical communities. In the case of one dedicated Qubes user, the optimization of isolation across various domains of life (e.g. work, personal, activism…) resonates with her decade-long activist experience: increased crackdowns and beatings of activists in her country spurred her to develop separate personal and professional identities as a safety strategy. Over time, she found that it became “natural” among her social groups to go by nicknames in “real life,” “so you could do a Google search of each and they wouldn’t be mixed” (Interview #40).
But how does the counter-imaginary of compartmentalization oppose the dominant imaginary of unavoidable surveillance? We hone in on the following two elements: domain isolation and anticipation. The first, borrowed from computer security and engineering, encourages users to envision their life as a series of distinct, separate “cubes,” linking up the technical idea of digital isolation with the above Qubes user’s analog strategy of identity management. A civil society technology manual called “Zen and the art of making technology work for you” (Tactical Tech Collective, 2015) reads,
There are various approaches to digital security, but one of the most realistic approaches is security by isolation, which assumes that all security measures have their holes and therefore focuses on harm reduction by preventing possible attackers from accessing the “whole system” that needs to be secured.
Qubes developers in fact argue that the field of computer security has long suffered from a persistent problem with digital domain isolation. A lack of effective isolation means that if one part of a machine is compromised, the rest can easily follow. In recent years, the computer security community has addressed issues around domain isolation with workarounds such as “virtual machines” and other contained computing environments, which aim to provide an extra “wall” between everyday computing experiences and unpredictable threats. However, running a system full of virtual machines can be an inconvenient and challenging proposition, causing problems with computing speed and memory, and requiring users to adapt to a new “flow” that is “not part of your body” (Interview #11). Here Qubes intervenes, offering a system built from the bottom-up to optimize for compartmentalization, while allowing its users to shape its particularities.
This control afforded to users, however, creates its own demands. Qubes comes with no default setting that would take care of every potential risk or even guide the user toward the most effective way of dealing with particular hazards. The second element of the compartmentalization imaginary is thus anticipation. In order to make effective use of the secure pockets offered by Qubes, users must on their own anticipate how their data might be compromised by adversaries. In other words, they must effectively “reverse engineer” how their digital traces might be used against them and disassemble their daily life into fragmented information flows to create effective, separate “security domains.” They must subsequently reassemble their daily workflow in a way that maps compartments to anticipated threats. As one user explained, in order to set himself up with Qubes, he had spent considerable time beforehand brainstorming how to separate his data and “fit” his life experience into the OS set-up. Yet, “once I had installed Qubes, I had trouble actually using it. It was unclear how you would actually put data in it and use it in a practical sense” (Interview #27).
“Partitioning one’s digital life into security domains is certainly not an easy process and requires some thinking,” cautions Rutkowska (2011). “This process is also very user-specific,” she adds, acknowledging that what she has chosen to do might not align with the goals of others. In order to make the process of partitioning easier, Qubes held a workshop at a digital rights event, targeting a mix of digital security experts and human rights defenders. In this observed meeting, a Qubes volunteer demonstrated how she had gone about dividing her life into various subdomains, presenting a flow chart with four constructed “identities” classified as “public,” “persistent,” “pseudonymous,” and “professional,” with each mapping to a separate security domain. The volunteer then asked participants to create their own chart, identifying elements in their “digital lives” which “have a shared identity, have assets to protect, and denote high risk activities.” Participants, armed with paper and markers, took to the task of re-imagining their personhoods as a series of discreet data flows. They described the freeing and “greedy” feeling of wanting to create more and more “safe,” separate spaces for daily tasks and sensitive data. Yet, it was seen by some as a struggle to conceptualize how to effectively separate themselves into pieces—to understand which of the complex data flows of banal digital life do not in fact intersect?
The Qubes project constitutes a small-scale response to some of the particular problems of digital surveillance. The project tries to empower users to autonomously manage their digital life. By wiring isolated “safe spaces” into the mundane domain of networked computing, compartmentalization counteracts the dominant imaginary of presumed and unavoidable digital surveillance, “taming” its potentially destructive force. However, like other tools of its kind, the autonomy and safety it offers to users is tenuous and demanding of significant labor. The need for a user to engage in a sort of custom process of “dividuation” (Deleuze, 1992) and to successfully double-guess potential threats, puts the onus of responsibility for security on individual agency, a recurrent issue across technological interventions to surveillance harms (Kazansky, 2015). In addition, Qubes is limited in its ability to tackle the many issues adjacent to its immediate concerns with digital security, such as commercial privacy infringement, data exploitation, and algorithmic sorting. Interviewed Qubes users often tried to extend the affordances of Qubes into a tool to minimize data traces from online activities. This entailed the use of separate virtual machines for online shopping and social media in order to keep personal identities separate and thus frustrate commercial profiling. However, the users interviewed found it practically impossible to achieve this goal due to the many restrictions to anonymity imposed by commercial online platforms. Thus, while she feels digital security is practically possible, one of our Qubes users declared a sense of resignation vis-à-vis issues of privacy and tracking, lamenting that “the fight for privacy is a fight against windmills” (Interview #40).
Our analysis shows that Qubes is a “stabilized” response offering security in the face of pervasive digital surveillance. Yet, its inability to grapple with the menace of corporate data practices highlights the limitations of the project—and explains the pressure for civil society to continue evolving its tactics of response to technological harms. With the continuous shift in corporate data practices and infrastructures, Qubes users and the larger milieu of civil society actors concerned with data exploitation find reason to seek out new interventions, one of which we next explore.
Methods
Participant observation (2016–2019) took place at six sites across Europe, ranging from hacker space “meetups” to workshops at large conferences. For the Qubes case, we attended a workshop designed to help the project developers surface concerns and priorities around the user experience of the project, as well as a meeting bringing together its diffuse and international user community. For Dowse, we joined a meetup of tinkerers intervening into IoT, featuring a tool demonstration, and involved its core developers in a focus group.
