Repair from a Chair: Computer Repair as an Untrusted Cloud Service

Today, when people need their computers repaired, their process is not very different from hiring someone to fix a television: they either bring the computer to a repair service [1, 3], or they call a technician (or family member) and ask for a house call. This process is inconvenient. It also risks the privacy of customers’ data and the integrity of their systems: repair services have gained notoriety for stealing personal data from customers [22] or otherwise intruding on their privacy [7]. Remote desktops [2, 4, 5] avoid physical movement but still require that the customer make a choice. The customer can spend time and monitor the repairer (though many customers of repair services probably do not have the technical savvy to detect spurious actions in the first place). Or, the customer can save time and ignore the repairer, giving him carte blanche, just as if the computer were in the shop. Neither choice seems great. The purpose of this paper is to articulate a new vision for repair. This vision is motivated by three trends: • Software repairs. We surveyed retail repair services and learned that a large majority of repairs today involve software changes only (§2). Such repairs do not inherently require travel. • Virtual machines. Many computers today, even desktops, include virtualization technology, which could allow customers to ship their computers electronically [9, 19] (by sending the virtual machine image) and enforce guarantees against the repairer (by implementing protections in the virtual machine monitor). • Outsourcing. Service providers have long offered value-added services, such as desktop management and IT consulting. Lately, commodity computing has followed an analogous path, migrating to wellprovisioned, off-site, partially anonymous service providers (often known as the cloud). We call our vision repair from a chair: let a customer, at the press of a button, electronically ship a computer to a third party repairer whom the customer never meets; let the repairer be untrusted by the customer (meaning that the customer is protected against repairer error, whether accidental or intentional); and let the repair happen asynchronously. By asynchronously, we mean that the customer does not need to monitor the repair in real time. Note that the context for this vision is retail repair, in contrast with much academic work on troubleshooting [8, 11, 14, 15, 17, 18, 20, 21, 23, 25–28]. There, an experienced system administrator is faced with a complex configuration issue (say a subtly wrong token in httpd.conf), and this person trusts the troubleshooter (or they are the same person). In our setting, however, users are inexperienced (so much so that they would be unable to use the above-cited tools), the problems are relatively easy for the troubleshooter (as indicated by our survey), and the customer does not fully trust the repairer. Thus, the technical challenges in our scenario are different (though the tools above would be useful to the repairer so are complementary to our work). Our challenges are, first, to protect the privacy of the customer’s data. For example, if the repairer needs to correct a misconfiguration in a virus checker, he should not be able to see private vacation photos. We also have to protect the integrity of the customer’s system: if the repairer executes an invalid repair, a customer-side module should reject it or roll it back if the customer later discovers a problem. Last, we want to protect availability: the customer should be able to keep working during the repair. This requires a way to merge the repairer’s changes with those of the customer. A key building block for solving these problems comes from the rich literature on dependency tracking [8, 15, 17, 18, 20, 21, 23, 28] and, in particular, selective redo [11, 14], which we (ironically) use to protect against the repairer. We will also borrow other work, including virtual machine migration [6, 10, 19]. There are also new problems to solve: protecting customer privacy while allowing the repairer to work, statically validating repairs, merging the repairer’s changes with the user’s, dependency tracking across OS upgrades, coherently composing the aforementioned, and more. However, we do not yet have complete solutions. Rather, this paper’s primary contributions are articulating both the vision and the research agenda that must be addressed to realize it. Secondary contributions are targeting retail repair (which implies a new model: easy repairs but untrusted repairers) and conducting an inquiry of current retail repair services, which we report next.