Managing NymBoxes for Identity and Tracking Protection
aa r X i v : . [ c s . O S ] M a y Managing NymBoxes for Identity and Tracking Protection
Abstract
Despite the attempts of well-designed anonymous com-munication tools to protect users from tracking or iden-tification, flaws in surrounding software (such as webbrowsers) and mistakes in configuration may leak theuser’s identity. We introduce Nymix, an anonymity-centric operating system architecture designed “top-to-bottom” to strengthen identity- and tracking-protection.Nymix’s core contribution is OS support for nym-browsing : independent, parallel, and ephemeral web ses-sions. Each web session, or pseudonym, runs in aunique virtual machine (VM) instance evolving from acommon base state with support for long-lived sessionswhich can be anonymously stored to the cloud, avoidingde-anonymization despite potential confiscation or theft.Nymix allows a user to safely browse the Web using var-ious different transports simultaneously through a plug-gable communication model that supports Tor, Dissent,and a private browsing mode. In evaluations, Nymix con-sumes 600 MB per nymbox and loads within 15 to 25 sec-onds.
Today’s Internet users must increasingly assume that bydefault all of their online activities are tracked and thatdetailed profiles of their identities and behaviors are beingcollected by every Web site they visit [65], sold for mar-keting purposes [17, 53], and ingested into mass surveil-lance systems [59]. Users may wish to protect their on-line activities from being tracked or linked with their realidentities, however, or to access the Internet under sev-eral distinct roles , personas , or pseudonyms . Anonymityand pseudonymity are desirable to many types of users,from repressed minorities [66] and dissidents in authori-tarian countries [46, 33], to women wishing to hide theirpregnancies from advertisers [30, 31], to celebrity authorsdesiring “feedback under a different name” [73].Anonymity protocols such as Tor [15], Dissent [76],and Aqua [43] obscure a user’s network location, but client-side weaknesses can break this anonymity. Websites may still be able to track the user via third-partyplug-ins that circumvent the anonymous channel [55, 22],via browser fingerprints [19], employ software exploitsto “stain” the client for long-term tracking [56], or de-anonymize users directly [27, 61]. Anonymity-orientedLinux distributions such as Tails [68] and Whonix [75] Figure 1: Nymix is a client OS architecture designedto enable users to manage multiple roles in their onlinelife, and offer strong protections against their roles beingtracked or linked.mitigate some risks, but leave to the user the error-pronetask of managing different online roles or pseudonyms.Users can accidentally de-anonymize themselves by log-ging in to a sensitive account from the wrong browserwindow or otherwise neglecting to protect anonymityeven once [63], or by posting a photo without realizingthat the JPEG may contain GPS coordinates [52].To address this need we present Nymix, the first OS ar-chitecture designed to help users manage online roles, or nyms , and to protect these nyms systematically from ac-cidental or malicious linking. As illustrated in Figure 1,Nymix aims to offer end-to-end isolation between nyms,separating all client-side state and browser activity relatedto each nym into protected virtual machines, or nymboxes .Nymix connects these nymboxes to the Internet only viaseparate instances of network tracking protection systems,such as Tor, protecting nyms from being linked by the on-line services they are used to access.Nymix enables and encourages users to createephemeral, “throwaway” nymboxes on demand for activ-ities requiring no long-term state, such as reading news,reducing the user’s vulnerability to long-term tracking orintersection attacks [40]. Users can also create persistentnymboxes when needed, which can remember long-livedstate such as login credentials for pseudonymous Inter-net accounts. Unlike common password managers [1],Nymix maintains and structurally enforces an explicitbinding between each role a user plays online, the net-work login credentials related to each role, and all client-side state such as browser history related to each role. Bybinding client state and credentials to nymboxes, Nymixreduces the user’s risk of accidentally entering credentialsin the wrong context or browser window – when using the orrect nymbox the user need not enter those credentialsat all.Like Tails [68], Nymix can boot from a USB drive foreasy deployability and avoids leaving any history trail onthe host machine, offering deniability in situations whereinstalling anonymity tools may be dangerous or impossi-ble. Nymix encrypts and saves persistent nymbox stateto either local media or anonymous cloud storage. Bydefault, Nymix updates nym state only at explicit user re-quest (e.g., after the first login), and not after every brows-ing session, to protect the user from staining attacks onthe nymbox’s state, adding further deniability and historyprotection if the nym is ever compromised.Nymix has been under development for the past twoyears, predating public knowledge that governments usemalware to track [56] and de-anonymize users [27, 61],two key attack vectors that Nymix’s design addresses.Throughout its development, the prototype has undergoneregular design review and adversarial testing by an in-dependent red-team. The prototype is based on Ubuntu14.04, and uses two QEMU/KVM virtual machines foreach nymbox: one to run communication tools such asTor, and the other for the Web browser and associatedplugins. Nymix supports multiple pluggable anonymouscommunication systems including Tor, Dissent, and alightweight incognito mode that imposes minimal over-head but does not protect against network-level tracking.Our experimental results show that Nymix offers simi-lar performance to running the software natively or in sim-ilar software distributions, such as Tails. Nymix unsur-prisingly requires significantly more memory, however, aseach nymbox runs two virtual machines with all file sys-tem writes stored in RAM.This paper’s key contributions are: (1) an operating sys-tem architecture designed to help users keep local andonline state related to different roles isolated and pro-tected from tracking or linking; (2) a composable frame-work supporting pluggable anonymity tools, (4) anony-mous quasi-persistent nym storage either locally or in thecloud, (3) user-directed sanitization to control informationleaks across nyms, and (5) the ability to launch the user’sinstalled OS as a nym for deniability and history protec-tion.Section 2 identifies key challenges for anonymity andpseudonymity. Section 3 presents Nymix’s trust modeland architecture. Section 4 describes our prototype imple-mentation and our experiences with it. Section 5 evaluateshow well our architecture and prototype handle challengesmentioned earlier. Section 6 discusses related work. Sec-tion 7 reflects on other challenges and future work, andSection 8 concludes. This section motivates Nymix, and outlines the key chal-lenges it attempts to address, via two fictional scenarios.In the People’s Republic of Tyrannistan, the state-controlled ISP monitors all users’ traffic to censor andsuppress dissent. Bob, a Tyrannistani dissident wellaware of these dangers, uses Tor [15] at night to organizeprotests via his pseudonymous Twitter account [46, 33].Bob spends his days at the state-run newspaper, usinghis laptop to grind out grandiloquent paeans to GloriousLeader Tyrannistanus Rex IV. Bob may face imprison-ment if the censorware his job requires detects evidenceof unapproved activities on his laptop’s hard disk. Bobtherefore runs Tor only from a Tails USB drive [68].Bob could still be de-anonymized in many ways unlesshe is unerringly cautious. Since Tails (deliberately) for-gets all state after each session, Bob habitually logs intohis Twitter account anew each night – but if by force ofhabit he even once accidentally enters his Twitter creden-tials while not running Tails, he may be caught [63]. Bob’scomputer and his Web activity [19, 23] produce uniquefingerprints. Using an intersection attack [40], Tyran-nistani police can link Bob to his pseudonymous Twit-ter account. Bob might take a photo with his smartphoneat a protest and post it to his Twitter feed via Tor, notrealizing that the EXIF metadata in the photo containsGPS coordinates and his smartphone’s serial number [52].Even if Bob makes no such mistakes, the Tyrannistani po-lice might obtain a zero-day exploit, and use it againstBob’s browser to inject malware onto his running system,which reports his true IP and MAC address to the author-ities [27, 61].To improve his browsing experience, Bob begins exper-imenting with Tails’ persistent state that stores passwords,account settings, and applications on the same USB de-vice as Tails. Unfortunately for Bob, this opens him upto new types of staining [56] or fingerprinting, such asthe evercookie [38] that sticks around even if you disablecookies. In addition, the USB device now becomes evi-dence of Bob’s misbehavior . Tyrannistan police can con-fiscate the device, coerce Bob to decrypt its contents, andthen de-anonymize him.Life is easier for Alice in Freetopia: she does not feel inany imminent danger, and is doing nothing she thinks theFreetopian Fuzz care about. She has made some personalchoices that she is not ashamed of, and likes to discussonline in appropriate forums, but which she imagines herboss and work colleagues might not understand [66]. Sheis also concerned that the web sites she visits, and the adsthey present her, seem to know more about her than herown family does. She worries that these web sites might2igure 2: Block diagram of Nymix architecture. Thehypervisor hosts one or more nyms. Each nym has anAnonVM for browsing Web content by communicatingthrough the CommVM, which hosts the anonymizer. TheSaniVM offers sanitized access to local disks by sharingcontent scrubbed of personal information to AnonVMs.“out” her unannounced pregnancy by sending a streamof diaper ads while her family is around [30]. She findsthat the only way to keep such personal information secretis using cloak-and-dagger methods that might themselvesraise suspicions of criminal activity [31]. Thus, althoughAlice does not think anyone is “after her,” she would pre-fer to enforce a strong and inviolate barrier between heronline activities related to her work, her family and sociallife, and her unannounced preparations for motherhood. This section outlines the Nymix architecture, how it bindspseudonyms to client-side and network state and protectsnyms from being linked, and how Nymix addresses thechallenges discussed above in Section 2.
Nymix is designed from the ground up to offer usersstrong identity and tracking protection by giving them ex-plicit, first-class control over pseudonyms representing themultiple roles or personas they may use online. In con-trast with the large body of existing work attempting toimprove security or isolation between distinct users, or be-tween applications run by a single user, Nymix is the firstclient OS we are aware of to establish strong separationof roles through pseudonyms as a primary OS design ob-jective. Nymix places supervisory control over VM cre-ation, longevity, and destruction under the control of theuser, binding all client-side application state to a particularnym via a nymbox. To protect the ownership and relation-ships between different nymboxes, Nymix employs both anonymizers such as Tor and Dissent to protect againstnetwork-level linkage, and giving the user a full-featurednetwork client with the context of each nym, but deliber-ately making it difficult for the user to link nyms acciden-tally by posting the wrong file or cut-and-paste betweenthe wrong windows.With Nymix, for example, Alice may instantiate a nymto browse and check her e-mail, optionally loading the encrypted nym’s state anonymously from a cloud storagesystem to avoid leaving a “footprint” on her local ma-chine. During this process, she wants to check the lat-est news on Twitter and instantiates another nym, whichNymix works to keep unlinkable to the first. Finally, shewishes to post some content to her pseudonymous blog,doing that via yet another nym. She might discard thestate of some nyms after each session, to protect her moresensitive activities from long-term tracking and intersec-tion attacks [40], while preserving the state of other nymslocally or in cloud storage.As shown in Figure 2, Nymix’s most crucial compo-nent is its
Nym Manager , which manages nyms and sepa-rates all client-side browsing and other activities into sep-arate virtual machines or nymboxes for each nym. Eachnymbox in fact represents two virtual machines. All nor-mal client-side activity – such as running web browsers,their plug-ins, and other network-connected applicationssuch as mail clients – is confined to the appropriatenym’s
AnonVM . Nymix treats the guest OS and processesin each AnonVM as untrusted and potentially compro-mised [56, 27, 61], and for this reason permits no interac-tion between the AnonVM and the “outside world” exceptvia the nym’s corresponding CommVM . In this CommVMreside anonymity and circumvention tools, or anonymiz-ers such as Tor, which ensure that interaction betweenthe AnonVM and the Internet is further protected fromnetwork-based tracking.By isolating each nym’s AnonVM from its CommVM,Nymix ensures that software exploits against theAnonVM cannot compromise anonymity or link nymswithout also compromising the VMM. Launching a sep-arate CommVM for each nym with an independent in-stance of the anonymizer, in turn, ensures that even ananonymizer compromise in one nym will (hopefully) notcompromise other nyms. Separating CommVMs also en-sure that anonymizer state that is commonly shared orreused for efficiency, such as Tor circuits, cannot acciden-tally reveal the links between different nyms.NymBoxes have no access to local storage, i.e., the lo-cal hard disk and USB devices. To safely access personaldata, Nymix employs a SaniVM to isolate the user’s datato a single non-networked environment. The SaniVM san-itizes user data by either automatic or manual scrubbingof personally identifiable material from this data beforemaking it available to an AnonVM.
Nymix’s threat model assumes that an adversary may beable to compromise software within a particular AnonVMor CommVM, install software and inject software ex-ploits, and even gain root access within the VMs. How-3ver, Nymix assumes the adversary cannot access the hy-pervisor of a compromised VM nor the host’s file sys-tems. While state-level attackers most likely can compro-mise common VMMs including those Nymix uses [62],we do not set the unrealistic expectation of making com-promise impossible , but rather attempt to raise the barrierand cost to attackers significantly. We hope eventuallyNymix could be implemented in a certified kernel/VMMframework [41, 28], further increasing this barrier.As the CommVM hosts only anonymizing softwaresuch as Tor, an adversary can compromise a CommVMonly by attacking an anonymizer directly. Through a com-promised CommVM, the adversary may learn Nymix’spublic IP address. While the AnonVM may be compro-mised through remote exploits, the CommVM preventsanything in the AnonVM from learning the user’s IP ad-dress or other network or physical location information, solong as the anonymizer in the CommVM is not also com-promised. A compromised AnonVM or CommVM can-not trivially be linked to other AnonVMs or CommVMson the same host; however, attacks may be performed us-ing timing attacks and side channels [79, 80].Nymix cannot protect users who obtain compromisedcopies of Nymix itself, leaving the important problemof secure software distribution out of scope. We as-sume users obtain copies of Nymix through trustworthysources or verify their authenticity prior to use. Nymixalso does not improve the anonymity provided by theanonymizer, nor can Nymix prevent a user from explic-itly de-anonymizing themselves by typing their real nameinto an AnonVM for example.
Anonymizers such as Tor typically act as client-side Webproxies that redirect TCP connections through relays tohide their source. If the Web browser connected to thisclient-side proxy is misconfigured or vulnerable, how-ever, an adversary can exploit that vulnerability to bypassthe anonymizer: for example by invoking a plug-in thatfails to respect the browser’s proxy settings [55, 22], orby using malware to directly read and report the user’sIP address [27, 61]. Like Whonix [75], Nymix sepa-rates anonymizers from the user’s potentially vulnerableWeb browsing environment via two separate virtual ma-chines – an AnonVM and a CommVM, respectively. Un-like Whonix, which provides only a static user-managedpair of VM images, Nymix’s Nym Manager dynamicallylaunches and manages AnonVMs and CommVMs andmanages their state as part of a user-controlled nymbox.The user operates a nym primarily via the AnonVM,in which the web browser and other applications suchas E-mail clients run. Each AnonVM has a single vir- tual network link that connects directly, and only to, aCommVM, which runs an instance of the anonymizer forthis nym. The CommVM redirects all AnonVM traffic tothe anonymizer, which in turns transmits traffic throughthe anonymity network via the CommVM’s NAT-basedInternet connection. No software in the AnonVM evergets access to the physical host machine’s IP address,MAC address, or other physical devices or their trackabledevice identifiers.
Alternative Anonymizers:
Nymix treats theanonymizer as a pluggable module, and offers theuser a choice of several alternative anonymizers pre-configured to address different security/performancetradeoffs. A lightweight incognito mode uses simpleVPN relaying to provide low-cost anonymization withweak security. For more sensitive activities the usercan employ Tor, which offers excellent scalability andgood security against moderate adversaries. Finally,Nymix experimentally supports anonymous browsingvia Dissent [76], an anonymizer based on DC-nets [11]that in principle offers formally provable traffic analysisresistance and systematic protection against intersectionattacks [77], but is less mature and currently less scalablethan Tor. In principle, anonymizers can be combinedby connecting CommVMs in serial, or within the sameCommVM: we have built experimental Nymix configura-tions combining Tor and Dissent to achieve “best of bothworlds” anonymity, for example.While many modern browsers offer incognito or pri-vate browsing modes that promise to erase cookies, his-tory, and other state after a session, a single state manage-ment bug or security vulnerability in the browser can nev-ertheless render the user trackable [3]. Even in Whonix,such a state management bug – or malware-based stainattack [56] – renders the statically administered browserVM permanently trackable, and hence vulnerable to long-term intersection attacks, unless the user manually rein-stalls Whonix or resets it to pristine VM images. Byisolating both the browser and any such stains in a dy-namically managed AnonVM as part of an ephemeral-by-default nym, Nymix ensures that trackable stains disap-pear immediately when the nym does.
One of Nymix’s goals is to be small enough for users todownload conveniently and run from a typical USB drive,like Tails, to support users who wish to leave no trace oftheir sensitive Internet access activities on their comput-ers. A key practical challenge Nymix’s VM-centric de-sign presents, however, is that we effectively need to fitthe equivalent of at least three different VM images on the4ame USB drive: one containing the host OS atop whichNymix is built (currently Ubuntu Linux), the second con-taining an initial disk image for AnonVMs to use (contain-ing the web browser and other applications), and the thirdcontaining an initial disk image for CommVMs to use(containing Tor or other anonymizers). Supporting multi-ple alternative anonymizers as discussed above might fur-ther increase the number of VM images that Nymix wouldneed to “ship with.”To address this challenge, Nymix uses the OS imageinstalled on the Nymix USB as the host OS from whichthe hypervisor/VMM boots, as well as the basic VM im-age for all AnonVMs and CommVMs. To differentiatethese OS images to serve their distinct roles at runtime,Nymix employs union file systems, which logically stackmultiple file systems together while merging their con-tents. The union file system responds to file read accesseswith the contents of that file as it exists in the top moststack. The file system stores writes into the top most read-write layer, shielding lower layers from write access usingcopy-on-write.Live-bootable operating systems such as Tails often useunion file systems with the top layer using a temporary filesystem that resides in RAM. Nymix inserts between thebase image and the temporary file system an additional,intermediary configuration file system containing the con-figuration necessary to start the particular VM – e.g., oneconfiguration file system for its standard AnonVM con-figuration, and a separate configuration file system forthe CommVM representing each alternative anonymizerNymix supports. The changes this configuration file sys-tem makes include the network configuration files, the lo-cal startup script (/etc/rc.local), and the window managerstartup script.A nymbox’s temporary file systems store all writesto the file system in RAM. As a result, turning off apseudonym results in amnesia – Nymix wipes any tracesthat the pseudonym ever existed and securely erases theAnonVM’s and CommVM’s memory immediately onshutting down a pseudonym. The USB device used duringa Nymix session remains unchanged, ensuring that even ifconfiscated and thoroughly analyzed neither the computernor the USB device harbors evidence of Nymix use.After terminating a nym, Nymix removes all state ofthat nym from memory. As designed, Nymix and all otherexisting production solutions retain traces of that state un-til reboot; however, because the hypervisor cannot be ac-cessed without live confiscation, such state is likely to beinaccessible by an adversary. Recent work by Dunn [18]explores how much information remains on a host aftera virtual machine has shut down, yet the hypervisor re- mains active, as well as various methods for eliminatingit. Nymix could employ these methodologies to addressadversaries with physical access; however, many of thesefeatures require specialized hardware and additional com-putational overhead, so for now we assume that erasingAnonVM and CommVM memory after shutdown are suf-ficient.One security concern, created by Nymix’s reuse of thehost OS partition as AnonVM and CommVM images, isthat Nymix must ensure that the host OS partition is al-ways mounted read-only and never modified for any rea-son. This implies that any state the user wishes to persistacross boots – such as persistent nyms, as described below– must be stored elsewhere, either on different local disksor USB drives or in cloud storage. If Nymix ever permit-ted the host OS partition to be modified from its standard“distribution” state, those modifications, however minute(even mount-time or access-time updates) would mani-fest in the initial states of all AnonVMs subsequently cre-ated, potentially offering adversaries a way to track theuser. While Nymix by construction ensures that its hostpartition is only ever mounted read-only, it cannot pre-vent other operating systems from mounting the partitionread/write and potentially modifying it while the USBdrive is plugged in. Although not yet implemented, we in-tend to address this risk by adding a mechanism to checkall disk blocks loaded from the host OS partition intoan AnonVM or CommVM against a well-known Merkletree [26] as they are accessed, and safely shut down ratherthan risk vulnerability if a modified block is detected.
Although ideal from a tracking resistance perspective, a pure amnesiac system that never maintains persistent stateacross reboots would inhibit usability, effectively requir-ing users to re-initialize all browser configuration pref-erences during each session, and to re-enter login cre-dentials for any pseudonymous Internet accounts the usermight wish to access during the session. Worse, clientOS amnesia can reduce the security of users who regu-larly connect to pseudonymous accounts such as Alice’sdissident Twitter feed in Tyrannistan, in at least two ways.First, because Alice must enter her pseudonymous Twit-ter username and password during each session, this pro-cedure is likely to become habit – but if she ever evenonce accidentally performs this procedure outside of ananonymity-protected context (e.g., on some other Ubuntudistribution she may sometimes run with a GUI look-and-feel similar to Tails), she may be compromised [63, 45].Second, state-of-the-art anonymizers like Tor are more se-cure if they can maintain some state across boots – inparticular, Tor normally maintains the same entry relay quasi-persistent data . Quasi-persistent data re-sides on the machine only when actively in use. When notin use, an encrypted copy of the data is migrated to an-other storage device – either to another local partition orUSB drive, or to the cloud, akin to CleanOS [70]. Nymixallows users to store information and data accumulatedduring a pseudonym session anonymously into the cloud,thus retaining pseudonym information while leaving nopotentially “suspicious” state (even encrypted) on localdevices that might be inspected or confiscated.Nymix supports three different nym usage models: am-nesiac/ephemeral, persistent, and pre-configured. The lat-ter two both make use of quasi-persistent data, but withdifferent intent. In persistent mode, Nymix updates thenym’s stored state after each session, presenting a famil-iar and convenient state management model but increaserisk that the effects of a stain or other exploit attack in onebrowsing session will persist for the lifetime of the nym.In pre-configured mode, a user boots a nym once, con-figures it with appropriate software, settings, bookmarks,pseudonymous account credentials, and any other usefulstate, then directs Nymix to snapshot the nym. Each sub-sequent use of this nym then starts from this snapshot,never updating the stored nym state unless the user ex-plicitly requests another snapshot. Thus, a malware in-fection affecting one browsing session will be scrubbed atthe user’s next session, and even if the nym’s state is even-tually compromised, the attacker obtains no record of theuser’s client-side activities using the nym.
Workflow:
In a typical workflow, Nymix on bootpresents the user with a Nym Manager, offering optionsto start a fresh nym or load an existing nym . On firstuse, the user selects start a fresh nym . Each new nymbegins with a writable virtual disk image in a standard,pristine state. When done browsing, if the user opts tostore his nym, he returns to the Nym Manager and selects store nym . The user enters a name for the nym, a pass-word to encrypt it with, and an indication of a cloud ser- vice on which to store the nym. The Nym Manager navi-gates the user to the cloud service, using the CommVM’sanonymizer to protect this connection, and prompts theuser to login to the cloud service. In the background, thenym manager pauses the nym’s AnonVM and CommVM,syncs their file systems, compresses and encrypts theirtemporary file system disk images, resumes the VMs, anduploads the contents through the nym’s CommVM. Thenym manager notifies the user once the nym has beensaved, after which the user may close the nym or turn offthe computer.Later the user returns to Nymix and selects load an ex-isting nym . While the Nym Manager prompts the userto select the cloud service hosting the nym, Nymix startsan ephemeral nym for the purpose of gathering the nym’sstate anonymously from the selected service. As before,the nym manager directs the user to the cloud service’slogin page, and then prompts the user for the name of thenym and the decryption password. In the background, thenym manager downloads the nym’s state, and terminatesthe ephemeral nym used for downloading. The nym man-ager then proceeds to decrypt and decompress the loadingnym’s CommVM and AnonVM images, and resumes thenym by starting a new set of VMs using these images. Theuser may then continue using the nym. Security Tradeoffs:
The cloud storage solution has theadvantage of offering plausible deniability to a user whosedevices or USB drives may be inspected or confiscated.By utilizing free-to-use cloud storage options, such asDropBox or Google Drive, a user can create a pseudony-mous cloud account for each pseudonym. Because allinteractions with the cloud storage are anonymized, thecloud provider learns nothing about the account owner.Similarly, as pseudonyms store only encrypted data, cloudproviders learn nothing about the pseudonym therein.One subtle downside of the cloud approach is that theephemeral CommVM used to load a nym from the cloudcannot use the nym’s “proper” CommVM state – such asTor entry guards – because that CommVM state has notbeen retrieved yet. While we do not expect it to be easyfor an attacker to correlate the loading of the nym’s statethrough the ephemeral CommVM with the user’s actionsusing the nym’s own stateful CommVM, a sufficientlypowerful and all-seeing attacker might in principle do so,making this ephemeral CommVM one remaining point ofvulnerability to long-term intersection attacks. One solu-tion is for the user simply to use local storage instead ofthe cloud. Another possible solution we are exploring is to seed critical CommVM state such as entry guard choicesusing a deterministic hash based on the nym’s storage lo-cation and password, ensuring that the same seed (and6ence same entry guard choices) get used even by theephemeral CommVM that load the nym.
Users may want to distribute content from non-anonymous sources – e.g., Bob wants to post pictures hetook on his digital camera of the day’s protests in Tyranni-men Square. Na¨ıvely posting such files are risky, as theymay leak the user’s identity via GPS coordinates in EXIFmetadata for example [8, 10, 52].To mitigate such risks, Nymix never gives a nymboxdirect access to files on the client machine’s installed OS.Instead, Nymix delegates this responsibility to a dedi-cated, non-networked sanitation VM or SaniVM. Withinthis SaniVM, the user can access files on the installed OSand transfer files between nyms, via scrubbing tools thatassist the user in transferring files safely.Upon boot, Nymix searches the computer for file sys-tems unrelated to Nymix and mounts them in the SaniVM.Within this SaniVM the user can browse through allfiles on the computer and select files for transfer intoa nymbox. Prior to making any data accessible in thenymbox, however, the SaniVM launches a suite of scrub-bing tools that inspect the files to be transferred, attemptto identify potential risks such as hidden metadata or vis-ible faces in photos, present the user a list of these filesand potential risks, and offer to apply appropriate scrub-bing transformations under control of the user to removepotentially identifying personal information.Nymix creates a unique directory within the SaniVMfor each nym. The SaniVM detects when the user movesfiles into this directory and launches the scrubbing work-flow. Once scrubbing completes, the SaniVM finallycopies the file into a directory visible to the appropriatenym’s AnonVM.The SaniVM’s scrubbing process builds on the Meta-data Anonymization Toolkit (MAT) [71], but Nymix addsatop MAT both additional anonymization methods anda more user-friendly workflow incorporating automatedrisk analysis and identification, enabling the user to se-lect among alternative transformations, which might beseen as corresponding to different “paranoia levels.” Withimages, for example, the user might choose any combi-nation of: (a) scrub EXIF or other metadata, (b) blur anydetectable faces using OpenCV [2], and/or (c) reduce theresolution and add noise in attempt to disrupt any water-marks the image might contain unbeknownst to the user.With PDF or DOC files, the user can similarly scrub meta-data, but also has the option to reconstruct the documentcompletely as a series of bitmaps, effectively scrubbingany nonvisual information that might be concealed (acci- dentally or intentionally) in document’s complex text orvector graphics structures.While Nymix builds on a wealth of existing techniquesto strip files of potentially identifying material [4, 6, 67,71], clearly no scrubbing suite can be perfect. Develop-ers continuously create new file types, and add extensionsto existing file types, which might conceal identifying in-formation. Adversaries can also find improved ways toexploit existing file types. Nevertheless, by designingpersonal information detection, analysis, and scrubbinginto Nymix’s only cross-nym file transfer path, we hopeNymix’s architecture will ensure that users are at leastmade aware of the risks and offered choices that increasesafety in common-case situations.
Even if a user boots Nymix from USB, he likely alreadyhas a conventional OS installed on the machine, which hemay use for common non-sensitive, non-anonymous ac-tivities. This installed OS is likely to have network-relatedstate such as WiFi passwords or VPN software the userregularly employs to access local networks. To reduceNymix’s deployment burden and network configurationeffort required on startup, Nymix can boot the machine’sinstalled OS in a (non-anonymous) nymbox, and lever-age its existing state to sign onto relevant WiFi LANs, orenable the user to find (or create) files on his installed sys-tem that he may wish to transfer to nyms via the SaniVM,using already-familiar applications on the installed OS.Nymix can currently boot several versions of Windowsand Linux in this way.The three keys challenges for installed OS nyms thatdiffer from traditional nyms are booting the OS in a VM,addressing persistency, and specifying network configu-ration parameters. While Linux usually boots without is-sue, booting in a VM a Windows instance installed on the“bare metal” can trigger device driver complaints. Wefound that a standard repair process typically addressesthis problem, however.A user’s installed OS may of course be compromisedwith malware or censorware [42] that may attempt to trackor fingerprint the user. To maximize the safety of bootingthe installed OS, Nymix treats the machine’s hard disk asread-only and boots the installed OS into a copy-on-writevirtual disk, so that no changes the installed OS makeswhile running under Nymix ever persist on the physicaldisk it was booted from. This design: (a) ensures thatthe user will not need to run a repair process again whenswitching back to the installed OS on the bare metal; (b)ensures that any other unexpected glitches caused by boot-ing the installed OS in a VM cannot unexpectedly breakthe installed OS image on the underlying disk; (c) avoids7eaving any history indicating Nymix’s use on the localdisk, offer the user plausible deniability.If a user needs persistence, he may explicitly allowwrites back to the physical disk, or store his copy-on-writeCOW disk as quasi-persistent data. If he subsequentlystarts his installed OS outside of Nymix, however, it mayneed to be repaired again, as in the case of Windows. Fur-ther, attempting to use the quasi-persistent COW disk af-ter the underlying disk has changed can lead to inconsis-tency or corruption. Thus, we consider it safest to treat theinstalled OS as read-only, and leave exploration of moresophisticated alternatives to future work.
Our prototype Nymix systems implements the architec-ture discussed in Section 3 including support for variousanonymizers, circumvention tools, and sanitization tech-niques. Nymix uses the Ubuntu 14.04 64-bit Linux dis-tribution and QEMU/KVM for running all nymboxes, be-sides Windows Host OS nyms. We have yet to consol-idate nym activity to a single interface; instead we usethe graphical user interface of each AnonVM to host thenym’s Web browser. The Chromium Web browser waschosen in order to support circumvention software, specif-ically StegoTorus [74]. We have released Nymix sourcecode, packages that build a fresh Nymix disk image, andNymix images at blinded url . Nymix has the necessary configuration to supportanonymizers, circumvention tools, and other communica-tion tools that use either a SOCKS [44] or virtual networkinterfaces, such as a tap device. The entire run-time con-figuration for these tools resides within the CommVM,running completely transparent to the AnonVM. WhileTor does not support UDP redirection, it has a built-inDNS server. Dissent, on the other hand, does have sup-port for UDP redirection. For tools that support neither,Nymix would need to convert UDP-based DNS requeststo TCP before transmitting them over the communicationtool.Currently, we have tested the following tools withinNymix: Tor [15], Dissent [76], our own implementationof SWEET [32], and an incognito mode. Tor has a built-in DNS server, while both Dissent and SWEET supportUDP based proxying. Our incognito mode makes use ofLinux’ IPTables masquerade mode in order to provide aNAT interface into the Internet.
For virtualization, Nymix primarily depends onKVM [57], a virtualization solution built directlyinto the Linux kernel. KVM builds upon and recentlymerged with QEMU [5] and takes advantage of hardwarevirtualization, where available.The hypervisor configures the network on the AnonVMto talk directly to the CommVM via a UDP port, effec-tively setting a virtual wire connecting the two machinesor a host-only network. Because that UDP sockets run inthe hypervisor, only applications in the hypervisor can ac-cess it. The CommVM connects to the Internet by way ofKVM user-mode NAT.Nymix configures the VM to reduce the ability for anadversary to fingerprint a VM. Each independent set ofAnonVMs and CommVMs have the same Ethernet andIP addresses. The resolution within an AnonVM is con-sistently set to 1024x768, albeit that is configurable up-wards and downwards, we want Nymix to run the sameon every machine. Each VM has only a single CPU listedin /proc/cpuinfo as a QEMU Virtual CPU. The VM has256 MB writable storage and 256 MB RAM, both of theseconsume the host’s RAM.Nymix enables KSM or kernel samepage merging.KSM is a memory-saving de-duplication feature thatscans pages and merges when applicable. Because allNymix VMs and the hypervisor use the same disk imageand hence applications, Nymix can save a bit of RAMthrough the use of KSM, as we show in our evaluations.Nymix stacks the file systems together using Over-layFS, a union file system built directly into the Linux ker-nel. Each VM has three file systems: 1) the base image,2) a configuration image, 3) and a writable image. Thehypervisor and VMs all share a common base image, thisis the OS installed on the USB stick. The configurationimage masks configuration files on the base image to en-able AnonVM, CommVM, or SaniVM functionality. Thewritable image can either be tossed at the end of a sessionor stored in the cloud for quasi-persistent data stores.Many modern virtual machine management tools sup-port loading a real path within the hosts file systemonto a guest. KVM makes use of VirtFS [37]. WithinNymix each of the different configuration file systems ex-ists as paths within the disk image. When starting thepseudonym VMs, Nymix attaches the appropriate path tothe VM as a VirtFS.
The SaniVM hosts a multipurpose scrubbing tool that wedesigned. The scrubbing tool runs in two modes, the firsttakes advantage of MAT [71], the Metadata Anonymisa-8ion Toolkit. The second mode converts the document intoa series of images, effectively loading the document into aproper viewer, taking one or more screen shots, and thenassembling the images together. Both tools strip awaymetadata; however, our extension does so by requiringonly a viewing tool and not a tool that has explicit knowl-edge about what fields should be stripped. Of course, amalicious entity may embed visible content that neitherstripper can remove.After scrubbing, the SaniVM moves it into a sharedfolder with the hypervisor. The hypervisor, then inturn, moves it into a shared folder with the specificAnonVM. KVM includes a shared folder technologycalled VirtFS [37].
We validate the Nymix prototype using KVM and nestedvirtualization This process made it easy to verify the stateof the system and inspect for potential information leaks.To check for leaks, we connected the Nymix hypervisor toa virtual network interface that tunneled traffic to a NATrunning on the host. On the host device, we ran Wire-shark and inspected traffic entering and exiting an idleNymix client. The Nymix hypervisor emitted only traf-fic for DHCP and anonymizer traffic, while the AnonVMtransmitted no traffic.We also started many pseudonyms simultaneously inorder to verify the restricted communication model. Weattempted to transmit Ethernet and IP packets from oneAnonVM as well as one CommVM to the local network,other AnonVMs and CommVMs, as well as the hypervi-sor. All attempts failed with a no-response, as if the hostdid not exist. The AnonVM can only communicate with afunctional CommVM and the CommVM could only com-municate with the Internet not local intranets.Beyond internal validation, Nymix has been regularlyscrutinized for over 2 years by an independent red-team.
As users explore the new functionality provided byNymix, there will be a natural increase in pseudonym us-age. Each additional pseudonym costs RAM as well as in-duces network and CPU overhead on other pseudonyms.In this section, we investigate these overheads in a seriesof experiments using an Intel I7 quad core desktop withhardware virtualization extensions and 16 GB of RAM.The desktop connects to a test Tor deployment runningon the DeterLab testbed that eventually reaches the realInternet. The network connection between the DeterLabtestbed [13], has a round trip latency of 80ms and through- put and has been rate limited to 10 Mbit/s through theLinux tool qc, the DeterLab testbed has no additional de-lays or bandwidth constraints. While we could use the realTor network, our evaluations focus on the overheads ofNymix and not noise introduced by the dynamic and com-plex nature of Tor. To analyze overheads, the VMs usedtwo different memory configurations. Our CPU bench-mark, Peacemaker, demanded around 1 GB of RAM,whereas, bandwidth and regular Web access required only384 MB of RAM. In all tests, we allocated 16 MB diskspace and 128 MB RAM to each CommVM and 128 MBdisk space to each AnonVM. The host allocates disk andRAM from its own stash of RAM, thus limiting the max-imum number of nyms.To evaluate memory per pseudonym, we launched aseries of pseudonyms in succession. Upon loading apseudonym, we checked the current used memory andkernel samepage merging (KSM) shared pages. We theninteracted with a website and again noted the used mem-ory and shared pages. At which point, we loaded anotherpseudonym and repeated producing 8 different nyms. Weaccessed the following websites in order: Gmail, Twitter,Youtube, Tor Blog, BBC, Facebook, Slashdot, and ESPN.Where applicable, we signed into Web sites and simulatedsome typical user behaviors, such as reading the latestnews. Our results, Figure 3, show that KVM obtains mostof the requested memory for a VM at VM initializationand not during run time. We also see that as more VMsare allocated, KSM manages to reduces overall memoryusage resulting in over 5% saving at 8 nyms.To evaluate CPU overhead, we ran a Javascript bench-mark called Peacekeeper [25] in several pseudonyms, si-multaneously. Unfortunately certain experiments withPeacekeeper consume too much memory causing Chrometo crash, therefore we had to increase the RAM allocatedto the AnonVM for this evaluation. We ran the evaluationwith up to 8 pseudonyms and present the results in Fig-ure 4. In this graph, 0 represents the system running innative mode. Virtualization incurs about a 20% overhead.When running Peacemaker in parallel, the actual perfor-mance outperforms the expected results, based upon thesingle nyms performance when run multiple times per-fectly in parallel with other nyms. These results indicatethat CPU performance overheads, while apparent, shouldnot be a significant impediment to Nymix scalability.Each additional nym uses its own instance of ananonymizer incurring additional bandwidth overhead dueto control messages. In this evaluation, we download thecurrent Linux kernel version 3.14.2, from a server runningwithin DeterLab in order to guarantee the 10 Mbit down-load rate. We varied the number of parallel downloading9 M B N u m be r o f P age s Number of NymsShared pages (after)Shared pages (before)Expected memoryUsed memory (after)Used memory (before)
Figure 3: RAM usage and sharedpages with varying number ofpseudonyms before and after the newpseudonym becomes active. The dashline represents the estimated cost inRAM per-pseudonym. A v e r age P ea c e k eepe r S c o r e Number of NymsActualExpected
Figure 4: Accumulated valuesfor parallel running instances ofPeacekeeper running in indepen-dent pseudonyms. 0 represents theevaluation when run directly on thehost.
50 100 150 200 250 300 350 400 450 500 550 600 1 2 3 4 5 6 7 8 D o w n l oad T i m e ( S e c ond s ) Number of NymsActualIdeal
Figure 5: Time to download the Linuxkernel with many nyms downloadingin parallel. 0 represents the evaluationwhen run directly on the host.nyms and present the results in Figure 5. As we scale thenumber of nyms, the performance remains relatively lin-ear, indicating that Tor, the anonymizer in the CommVM,has a fixed cost, approximately 12% overhead. Perfor-mance on the real Tor network may differ significantly.
To evaluate the storage requirements for quasi-persistentpseudonyms, we monitored the size on disk of the nymstate across ten save/restore cycles over the course of threedays. Both the AnonVM and CommVM were equippedwith 256 MB disks. We performed the experiment withfour different nyms each visiting a different site: Twit-ter, Facebook, Gmail, or the Tor Blog. We began bylaunching a new pseudonym, visit the website, sign-inwhen applicable, and configure the browser to remem-ber login information. We then closed the browser andsaved the pseudonym to cloud storage. For all subsequentmeasurements, we restored the nym from cloud storageand launched the browser, triggering a fetch of any newsite updates. After the page finished loading, we closedthe browser, and, in the case of persistent nyms, savedthe pseudonym back to cloud storage. For each uploadwe recorded the size on disk of the archived, encryptedpseudonym image.We present the results of our experiment in Figure 6.Persistent nyms do grow over time with the AnonVM con-tent accounting for of the pseudonym size, thoughmuch of that is dominated by contents in Chromiumcache, which could have been configured to be smallerthan the default of 83 MB. Effectively a single save cyclerepresents usage similar to a pre-configured nym, whichtends to be small in the order of megabytes.
To evaluate the overhead incurred by starting a freshnym and restoring a quasi-persistent nym, we compared startup times for the three different nym usage mod-els: ephemeral, pre-configured, and persistent. For eachconfiguration, we visited the Twitter website and re-trieved updates. Upon finishing the page load, we closedthe browser and, in the first two models, discarded allchanges. For persistent nyms, we saved all changes backto the persistent state. We further divided pseudonymstartup time into three phases: AnonVM boot time, Torstartup time, and webpage load time. For quasi-persistentnyms, we include the time it takes to start an ephemeralnym, download the state from the cloud, decrypt it, andprepare a new nym encapsulated as “Ephemeral Nym”We timed five executions from each initial configurationand present the averaged results in Figure 7. Quasi-persistent nyms consistently outperform ephemeral nymsdue to stored Tor state; however, they require a one-timeuse ephemeral nym to download the data as well as userinteraction necessary for authentication and nym selec-tion, which was not measured in this evaluation. In prac-tice, we expect user-interaction to play a significant rolein nym boot times.
Running an installed OS as a nym requires both user inter-action and computation resources. User interaction comesin the form of a user executing commands to repair the OSto support the change of hardware. The repair process an-alyzes the OS state and performs some reconfiguration.While hard to separate the human process from the auto-mated process, this evaluation takes a look at both the timerequired to perform this process and the resulting impacton memory. Finally, after repairing the OS, the operatingsystem can be booted as a nym. We present the resultsin Table 1. Memory sizes suggest that the repair processis quite invasive, suggesting that perhaps there may be amore intelligent means to automating this process. Ideallywe could automate the repairing of the OS in the back-10 E n c r y p t ed s i z e ( M B ) Save/restore cyclesGmailFacebookTwitterTor Blog
Figure 6: Sizes of quasi-persistent pseudonym dataacross save/restore cycles. T i m e ( s ) Boot VMStart Tor Load webpageEphemeral Nym
Figure 7: Average startup time by phase for each initialconfiguration.ground, merging the time a repair takes with the bootingprocess of Nymix and the associated CommVM.
Repair (S) Boot (S) Size (MB)Vista 133.7 37.7 4.97 129.3 34.3 4.58 157.0 58.7 14
Table 1: Time and memory costs of using various versionsof Windows as a nym in Nymix.
The Nymix project bears resemblance to other safety-focused bootable media projects. Tails [68] uses externalbootable devices which have been preconfigured with Tor,the Tor version of Firefox, and other utilities for privacyprotection. Like Nymix, Tails supports persistent state;however, Tails stores that state on the same USB as Tails.Even if the data is encrypted, a sufficiently powerful ad-versary could likely coerce the key from its owner. Nymixoffers deniability by storing persistent state anonymouslyto the cloud. Because of the large community surround-ing Tails, we view Nymix as a development platform forresearch ideas that eventually will be integrated into Tails,namely, structural protection such as nymboxes and quasi-persistent data.Like Nymix, Whonix [75] separates the user environ-ment from the communication tool eliminating accidentalinformation leaks due to faulty component configurations.Unlike Nymix, Whonix installs a pair of virtual machineson the users installed operating system. Unlike Nymix,Whonix cannot defend against hardware fingerprinting,confiscation, or correlation attacks.Similar to how Nymix isolates user data into a sin-gle environment, the SaniVM, the US military [39] andNSA [49] have made similar efforts to separate classifiedand unclassified information. In fact, the US military’s ap-proach to separation entitled “secure shared file store op-tions” has a similar construction to Nymix’s use of VirtFSwithout requiring changes to the hypervisor. Nymix solves an important problem in the domain ofscrubbing, negligence in their use [8], by forcing their useas part of an OS primitive Earlier work proposes similarextensions for networks [35]. Nymix builds on MAT [71],but there are many other tools out there and metadatascrubbing may be insufficient. Even intentionally blindedconference papers leak personally identifiable informa-tion [4]. Bier [6] shows that removing keywords is in-sufficient and need semantic analysis, in effect, nothingwill be perfect. Data may be hidden by steganographyand there is not much a scrubber can do to prevent activesteganography [10].As an alternative to selecting files and folders to scrub,Nymix could employ concepts introduced by User-DrivenAccess Control [60]. In this model, a user could grantaccess to certain folders and files on the host to a specificnym. Nymix could then delay scrubbing of files until thefiles have been accessed from within the nym.The notion of pseudonyms long predates anonymousdigital communication. Recent work from Han et al. [29]explores the notion of a pseudonym browsing mode. Theirwork focuses on a network adversary who links usersprimarily by IP addresses. To mitigate the effective-ness of this adversary, each pseudonym runs in the sameOS but within different browser profiles and IPv6 ad-dresses. Their approach requires infrastructure changesto deployed IPv6 routers in order to support multiple IPv6addresses at the same site that could not easily be corre-lated, effectively creating a one hop proxy or a VPN. Theyhave also implemented a plugin to address adversariessimilar to Panopticlick [23]; however, this is an arms raceand the plugin will need to be maintained in order to en-sure that future fields do not leak information. Nymix’sstructural approach to homogeneity offers a future proofarchitecture that remains immunity to these types of at-tacks.On the other end of the spectrum, there has been con-siderable work in using OS sandboxing to enhance isola-tion and resistance to compromised browsers and appli-cations, such as BOS [12], IBOS [69], and Atlantis [50].These approaches separate each web page instance into11nique processes that have access to a limited API in-tended for web browsing only. However, this work hasyet to address the need for pseudonymity and anonymity.Similar efforts have been made to offer separation oncontent in general and not just Web interaction [51], afeature Nymix also seamlessly offers. Nymix currentlyuses virtual machines to offer sandboxing, but architec-turally Nymix could in principle sandboxing could be of-fered by lightweight process-level sandboxes [51], soft-ware fault isolation [72, 78], enhanced browser-basedsandboxes [69, 50, 34, 12], virtual machines [12], or evenhosting Nymix instances in the cloud [48].Nymix could be extended in many directions. A nymonly isolates identities, but could benefit from approachesthat isolate and protect sensitive data in a browser, suchas Configurable Origin Policies [9], TaintDroid [21], andCrypton-Kernel [16]. While Nymix might isolate a keylogger, ScreenPass [47] could offer Nymix a means to se-cure password entry to avoid spoofing attacks by provid-ing a trusted password entry keyboard.
The Enemy Within:
The Nymix model depends on thesterility of both hardware and software. A malicious partycould install malware into the hypervisor prior to distribu-tion or in the firmware of WiFi devices prior to a party inorder to compromise a user’s anonymity. Using trustedplatform modules could potentially ensure the runningsoftware and firmware; however, all is for naught if thehardware vendor has conspired with the adversary.
Lack of Perfect Homogeneity:
Even while using virtu-alization and the same set of software, there still exists thepossibility for differences between users. An adversarycould execute a particularly CPU intensive application,such as a Javascript application that computes a milliondigits of PI, and use the timings to produce a fingerprintfor that user. Also, all users cannot necessarily be in thesame location, and hence if there is a single Tor user inTyrannistan, the government-owned ISP could easily de-termine the responsible party for any Tyrannistani trafficrelated to Tor.
Long Term Intersection Attacks:
Nymix mitigates in-tersection attacks by reducing a user’s fingerprint; how-ever, a fingerprint can be developed even if the user em-ploys amnesia simply by the set of websites he visits orthe accounts used on those sites. An adversary performsan intersection attack [58] by tracking the online set ofparticipants and discovering a set of linkable, yet anony-mous messages. The adversary constructs an intersectionof users that were online at the same time as those link- able messages. With sufficiently many number of mes-sages, the adversary will be able to discover the owner ofthe linkable messages. To enhance Nymix’s ability to re-sist intersection attacks, we plan to integrate Buddies [77].Buddies offers users anonymity metrics and safe guards auser from falling below a desirable anonymity threshold.
Concealing Network Identity:
Network identityproves difficult even in the Nymix context. Networkfingerprinting comes in many forms from operatingsystem interfaces to NIC devices [54], drivers [24],MAC addresses, and even the hardware characteristics ofdevices [7]. Some of these attacks are avoidable usinga common device with a standardized driver, a volatilemanagement framework for the device, and randomizedMAC addresses.For well-equipped adversaries, this approach is insuffi-cient. Brik et al. [7] determined that even devices from thesame manufacturer with sequential serial numbers couldbe fingerprinted due to the errors in the signal. Sincewe envision that Nymix may be used in moderately well-organized groups, we posit that users could organize WiFidevice exchange parties, or WiFi social mixes, akin toRichard Stallman’s “Charlie Card” swapping parties [64]to elude RFID-based fingerprinting. During these parties,each member would place their cards in a box. Aftercollecting all members’ cards, each member would ran-domly select one without knowing which had been takenand which were left. Users might have many such parallelexchanges, so that a user could have several WiFi cardsat a time. In addition, individuals could use an active an-tenna to ambiguate their location as well also to changethe physical properties of the device’s transmissions.
Nymix offers novel structural solutions for managing on-line identities or pseudonyms. In contrast to existing sys-tem solutions for anonymity and pseudonymity, Nymixprovides completely independent state for each of theuser’s identities. Nymix, however, does not subsume orreplace the need for other techniques or hardened systems.We believe Nymix offers a useful platform for researchingWeb browsing pseudonymity that should eventually be in-corporated into Tails and similarly hardened systems.
References [1] KeePass. http://keepass.info/ .[2] OpenCV. http://opencv.org .[3] G. Aggrawal, E. Bursztein, C. Jackson, andD. Boneh. An analysis of private browsing modes12n modern browsers. In
Usenix Security Symposium ,2010.[4] T. Aura, T. A. Kuhn, and M. Roe. Scanning elec-tronic documents for personally identifiable infor-mation. In , pages 41–50, New York, NY,USA, 2006. ACM.[5] F. Bellard. QEMU, a fast and portable dynamictranslator, Apr. 2005.[6] E. Bier, R. Chow, P. Golle, T. King, and J. Staddon.The rules of redaction: Identify, protect, review (andrepeat).
Security Privacy, IEEE , 7(6):46 –53, nov.-dec. 2009.[7] V. Brik, S. Banerjee, M. Gruteser, and S. Oh. Wire-less device identification with radiometric signa-tures. In
ACM International Conference on MobileComputing and Networking (MobiCom) , pages 116–127, 2008.[8] S. Byers. Information leakage caused by hidden datain published documents.
IEEE Security and Privacy ,2:23–27, 2004.[9] Y. Cao, V. Rastogi, Z. Li, Y. Chen, andA. Moshchuk. Redefining web browser principalswith a configurable origin policy. In , June 2013.[10] A. Castiglione, A. D. Santis, and C. Soriente. Takingadvantages of a disadvantage: Digital forensics andsteganography using document metadata.
Journal ofSystems and Software , 80(5):750 – 764, 2007.[11] D. Chaum. The Dining Cryptographers problem:Unconditional sender and recipient untraceability.
Journal of Cryptology , pages 65–75, Jan. 1988.[12] R. S. Cox, S. D. Gribble, H. M. Levy, and J. G.Hansen. A safety-oriented platform for web applica-tions. In
IEEE Symposium on Security and Privacy(SP) , 2006.[13] DeterLab network security testbed, September 2012. http://isi.deterlab.net/ .[14] R. Dingledine. Improving tor’s anonymityby changing guard parameters, 2013. https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-parameters .[15] R. Dingledine, N. Mathewson, and P. Syverson. Tor:the second-generation onion router. In , Aug. 2004. [16] X. Dong, Z. Chen, H. Siadati, S. Tople, P. Saxena,and Z. Liang. Protecting sensitive web content fromclient-side vulnerabilities with CRYPTONs. In , Nov. 2013.[17] C. Duhigg. How companies learn your se-crets.
The New York Times , Feb. 2012. .[18] A. M. Dunn, M. Z. Lee, S. Jana, S. Kim, M. Silber-stein, Y. Xu, V. Shmatikov, and E. Witchel. Eternalsunshine of the spotless machine: Protecting privacywith ephemeral channels. In
USENIX Symposiumon Operating Systems Design and Implementation(OSDI) , 2012.[19] P. Eckersley. How unique is your web browser? In
Privacy-Enhancing Technologies Symposium , July2010.[20] T. Elahi, K. Bauer, M. AlSabah, R. Dingledine, andI. Goldberg. Changing of the guards: A frameworkfor understanding and improving entry guard selec-tion in tor. In
Workshop on Privacy in the ElectronicSociety (WPES) , 2012.[21] W. Enck, P. Gilbert, B.-G. Chun, L. P. Cox, J. Jung,P. McDaniel, and A. N. Sheth. Taintdroid: Aninformation-flow tracking system for realtime pri-vacy monitoring on smartphones. In
USENIX Con-ference on Operating Systems Design and Imple-mentation (OSDI) , 2010.[22] G. Fleischer. Attacking tor at the application layer. http://ww.defcon.org/images/defcon-17/dc-17-presentations/defcon-17-gregory_fleischer-attacking_tor.pdf ,July 2009.[23] E. F. Foundation. https://panopticlick.eff.org/ , Oct2013.[24] J. Franklin, D. McCoy, P. Tabriz, V. Neagoe,J. Van Randwyk, and D. Sicker. Passive data linklayer 802.11 wireless device driver fingerprinting. In
USENIX Security Symposium , 2006.[25] Futuremark. Peacekeeper –the universal browser test. http://peacekeeper.futuremark.com ,January 2013.[26] B. Gassend, G. Suh, D. Clarke, M. van Dijk, andS. Devadas. Caches and hash trees for efficientmemory integrity verification. In
High-PerformanceComputer Architecture (HPCA) , 2003.1327] D. Goodin. Attackers wield Firefox exploit to un-cloak anonymous Tor users. ars technica , Aug.2013.[28] L. Gu, A. Vaynberg, B. Ford, Z. Shao, andD. Costanzo. CertiKOS: A certified kernel for securecloud computing. In , July 2011.[29] S. Han, V. Liu, Q. Pu, S. Peter, T. Anderson, A. Kr-ishnamurthy, and D. Wetherall. Expressive privacycontrol with pseudonyms. In
ACM SIGCOMM , Aug.2013.[30] K. Hill. How target figured out a teen girl waspregnant before her father did.
Forbes , Feb. 2012. .[31] K. Hill. You can hide your pregnancy online,but you’ll feel like a criminal.
Forbes , Apr. 2014. .[32] A. Houmansadr, W. Zhou, M. Caesar, andN. Borisov. Sweet: Serving the web by exploitingemail tunnels.
CoRR , abs/1211.3191, 2012.[33] P. N. Howard and M. M. Hussain.
Democracy’sFourth Wave? Digital Media and the Arab Spring .Oxford University Press, Mar. 2013.[34] L. Ingram and M. Walfish. TreeHouse: JavaScriptsandboxes to help Web developers help themselves.In
USENIX Annual Technical Conference (ATC) ,June 2012.[35] S. Ioannidis, S. Sidiroglou, and A. D. Keromytis.Privacy as an operating system service. In
Proceed-ings of the 1st USENIX Workshop on Hot Topicsin Security , HOTSEC’06, pages 8–8, Berkeley, CA,USA, 2006. USENIX Association.[36] A. Johnson, C. Wacek, R. Jansen, M. Sherr, andP. Syverson. Users get routed: Traffic correlationon Tor by realistic adversaries. In , Nov. 2013.[37] V. Jujjuri, E. V. Hensbergen, A. Liguori, andB. Pulavarty. Virtfs–a virtualization aware file sys-tem pass-through. June 2010.[38] S. Kamkar. evercookie. http://http://samy.pl/evercookie/ ,oct 2010. [39] P. A. Karger. Multi-level security requirements forhypervisors. In
Computer Security ApplicationsConference, 21st Annual , ACSAC ’05, Dec. 2005.[40] D. Kedogan, D. Agrawal, and S. Penz. Limits ofanonymity in open environments. In , Oct. 2002.[41] G. Klein et al. seL4: formal verification of an OSkernel. In , Oct. 2009.[42] J. Knockel, J. R. Crandall, and J. Saia. In
Three Re-searchers, Five Conjectures: An Empirical Analysisof TOM-Skype Censorship and Surveillance , Aug.2011.[43] S. Le Blond, D. Choffnes, W. Zhou, P. Druschel,H. Ballani, and P. Francis. Towards efficient traffic-analysis resistant anonymity networks. In
ACM SIG-COMM , August 2013.[44] M. Leech et al. SOCKS protocol, Mar. 1996. RFC1928.[45] D. L. Leger. How fbi brought downcyer-underworld site silk road, 2013. .[46] M. Lim. Clicks, cabs, and coffee houses: Socialmedia and oppositional movements in egypt, 2004 –2011.
Journal of Communication , 62:231–248.[47] D. Liu, E. Cuervo, V. Pistol, R. Scudellari, and L. P.Cox. Screenpass: Secure password entry on touch-screen devices. In , June 2013.[48] L. Martignoni, P. Poosankam, M. Zaharia, J. Han,S. McCamant, D. Song, V. Paxson, A. Perrig,S. Shenker, and I. Stoica. In
USENIX Annual Tech-nical Conference (ATC) , June 2012.[49] R. Meushaw and D. Simard. NetTop: Commer-cial technology in high assurance applications.
TechTrend Notes , 2000.[50] J. Mickens and M. Dhawan. Atlantis: Robust, exten-sible execution environments for web applications.In , Oct. 2011.[51] A. Moshchuk, H. J. Wang, and Y. Liu. Content-based isolation: Rethinking isolation policy in mod-ern client systems. Technical Report MSR-TR-2012-82, Microsoft Research, Aug. 2012.1452] D. Oakes. Hacking case’s body of evidence.
TheAge , Apr. 2012.[53] OECD. Exploring the economics of personal data,Apr. 2013. OECD Digital Economy Papers No. 220.[54] J. Pang, B. Greenstein, R. Gummadi, S. Seshan, andD. Wetherall. 802.11 user fingerprinting. In
ACMInternational Conference on Mobile Computing andNetworking (MobiCom) , pages 99–110, 2007.[55] M. Perry. To toggle, or notto toggle: The end of torbutton. https://blog.torproject.org/blog/toggle-or-not-toggle-end-torbutton ,May 2011.[56] W. Post. GCHQ report on ‘MULLENIZE’program to ‘stain’ anonymous electronic traffic. http://apps.washingtonpost.com/g/page/world/gchq-report-on-mullenize-program-to-stain-anonymous-electronic-traffic/502/ ,oct 2013.[57] Qumranet. Kernel-based virtual machine for linux. http://kvm.qumranet.com/kvmwiki ,March 2007.[58] J.-F. Raymond. Traffic analysis: Protocols, attacks,design issues and open problems. In
Workshop onDesign Issues in Anonymity and Unobservability ,pages 10–29, 2000.[59] J. Risen and L. Poitras. NSA report outlined goalsfor more power.
The New York Times , Nov. 22, 2013.[60] F. Roesner, T. Kohno, A. Moshchuk, B. Parno, H. J.Wang, and C. Cowan. User-driven access control:Rethinking permission granting in modern operat-ing systems. In
IEEE Symposium on Security andPrivacy , May 2012.[61] B. Schneier. Attacking Tor: how the NSA targetsusers’ online anonymity.
The Guardian , Oct. 2013.[62] B. Schneier. Nsa surveillance: A guide to stayingsecure.
The Guardian , Sept. 2013.[63] E. Security. Notes on Sabu arrest, 2012. http://blog.erratasec.com/2012/03/notes-on-sabu-arrest.html .[64] J. Sedgwick. The shaggy god. ,May 2008.[65] A. Soltani, S. Canty, Q. Mayo, L. Thomas, and C. J.Hoofnagle. Flash cookies and privacy, Aug. 2009. [66] E. Stein. Queers anonymous: Lesbians, gay men,free speech, and cyberspace.
Harvard Civil Rights-Civil Liberties Law Review , 2003.[67] L. Sweeney. Replacing personally-identifying infor-mation in medical records, the scrub system.
Jour-nal of the American Medical Informatics Associa-tion , 1996.[68] Tails: The amnesic incognito live system, September2012. https://tails.boum.org/ .[69] S. Tang, H. Mai, and S. T. King. Trust and protec-tion in the illinois browser operating system. In , Oct. 2010.[70] Y. Tang, P. Ames, S. Bhamidipati, A. Bijlani,R. Geambasu, and N. Sarda. Cleanos: limiting mo-bile data exposure with idle eviction. In
USENIXSymposium on Operating Systems Design and Im-plementation , Oct. 2012.[71] J. Voisin, C. Guyeux, and J. M. Bahi.The metadata anonymization toolkit. http://arxiv.org/abs/1212.3648 ,may 2013.[72] R. Wahbe, S. Lucco, T. E. Anderson, and S. L. Gra-ham. Efficient software-based fault isolation.
ACMSIGOPS Operating Systems Review , 27(5):203–216,Dec. 1993.[73] R. Watts. JK Rowling unmasked as author of ac-claimed detective novel.
The Telegraph , July 13,2013.[74] Z. Weinberg, J. Wang, V. Yegneswaran, L. Briese-meister, S. Cheung, F. Wang, and D. Boneh. Ste-goTorus: a camouflage proxy for the Tor anonymitysystem. In , Oct. 2012.[75] Whonix. http://sourceforge.net/p/whonix .[76] D. Wolinsky, H. Corrigan-Gibbs, B. Ford, andA. Johnson. Scalable anonymous group communi-cation in the anytrust model. In
European Workshopon System Security (EuroSec) , Apr. 2012.[77] D. I. Wolinsky, E. Syta, and B. Ford. Hang with yourbuddies to resist intersection attacks. In , November 2013.1578] B. Yee et al. Native client: A sandbox for portable,untrusted x86 native code. In
IEEE Symposium onSecurity and Privacy , May 2009.[79] Y. Zhang, A. Juels, A. Oprea, and M. Reiter. Home-alone: Co-residency detection in the cloud via side-channel analysis. In
IEEE Security and Privacy SP(IEEE SP) , 2011. [80] Y. Zhang, A. Juels, M. K. Reiter, and T. Ristenpart.Cross-vm side channels and their use to extract pri-vate keys. In