{"id":1500,"date":"2019-05-21T18:00:17","date_gmt":"2019-05-21T22:00:17","guid":{"rendered":"http:\/\/resources.culturalheritage.org\/emg-review\/?page_id=1500"},"modified":"2019-11-01T15:43:38","modified_gmt":"2019-11-01T19:43:38","slug":"farbowitz","status":"publish","type":"page","link":"https:\/\/resources.culturalheritage.org\/emg-review\/volume-5-2017-2018\/farbowitz\/","title":{"rendered":"Archiving Computer-based Artworks"},"content":{"rendered":"\n

Jonathan Farbowitz
The Electronic Media Review, Volume Five: 2017-2018<\/em> <\/p>\n\n\n\n

ABSTRACT<\/h2>\n\n\n\n

Art\nmuseums throughout the world have been acquiring computer-based artworks with\nincreasing confidence. As artist-created hardware and software enter museum\ncollections, they present unique challenges for long-term preservation.\nConservation staff at these institutions face urgent questions regarding the\nnecessary elements required for acquisition and preservation as well as how to\ndefine their technical, functional, and conceptual constituents.<\/p>\n\n\n\n

Through\nthe lens of the Guggenheim\u2019s initiative on Conserving Computer-based Art in its\ncollection, this article takes a critical look at the physical and digital\nelements that museums acquire or generate in order to archive and preserve\ntheir computer-based artworks. Drawing from the Conserving Computer-based Art\ncollection survey and back-up project, which encompasses artworks dating from\n1989 to the present that employ a variety of technologies, the article provides\nan overview of collected digital assets and documentation and proposes elements\nthat museums should consider obtaining or creating in order to sustain the life\nof software- and computer-based artworks. The article makes recommendations for\ninformation to capture about the hardware and software dependencies and\ndiscusses why this documentation is important for future migration, recreation,\nor replacement of the equipment. Methods for collecting this information\nthrough examining the hardware itself and by using software built into the Windows,\nMac OS, and Linux operating systems are described.<\/p>\n\n\n\n

Disk imaging is introduced as a method of extracting data from artist-provided computers and physical information carriers (such as floppy disks and optical discs), as these carriers are not suitable for long-term data storage. The Guggenheim\u2019s disk imaging workflow is described in detail, including several methods for quality control of disk images after they are created. The article concludes with recommended deliverables for the acquisition of computer- and software-based artworks. <\/p>\n\n\n\n

INTRODUCTION<\/h2>\n\n\n\n

Artworks\nin which software and computer systems are employed as an artistic medium can\ntake many forms, including artist-created websites, custom computer programs,\nor complex installations that involve microcontroller units. New acquisitions\nof computer-based artworks (also known as software-based artworks) often\ninclude artist-created or modified hardware and software. As a result, museum\nstaff are faced with concerns about how to archive these collection items,\nincluding taking preventive measures to ensure the long-term accessibility of\ndata and documenting each component of the artwork for future conservators.\nFurther complicating matters, each artwork may use vastly different\ntechnologies and present unique requirements for long-term preservation. <\/p>\n\n\n\n

The\nSolomon R. Guggenheim Museum currently has 25 computer-based artworks in its\npermanent collection, dating from 1989 to 2018. The technologies represented\ninclude Flash animations, virtual reality experiences, Internet-connected\ninstallations, custom-coded robotics, and artist-modified computers. In order\nto research and develop best preservation practices for these works, the\nGuggenheim launched the Conserving Computer-based Art (CCBA) initiative in 2014\n(Dover 2016).<\/p>\n\n\n\n

The\ngoals of the initiative are surveying and archiving the computer-based artworks\nin the collection; deriving improved methods for collection care and new\nacquisitions; and in-depth case studies of selected artworks, including source\ncode analysis, documentation, and treatment. The case study work of the CCBA is\nconducted as a cross-disciplinary collaboration between the Guggenheim\nConservation department and Department of Computer Science at New York\nUniversity (NYU). Research partners at NYU have annotated source code and\ncreated prototypes of code migration for artworks needing treatment.<\/p>\n\n\n\n

This\narticle reflects the research and findings of the first project phase of the\nCCBA initiative, the survey and backup of the collection, and explores measures\nthat can be taken to archive computer- and software-based artworks beginning\nwith their physical components (such as computers and microcontroller units)\nand information carriers (such as hard drives, floppy disks, and optical\ndiscs). The discussion then focuses on saving the digital assets stored on\nthese computers or information carriers. In certain cases, museum staff may\nneed to create additional digital assets for preservation purposes. A\nsignificant portion of the article examines disk imaging as one strategy for\narchiving the content of computers and information carriers and describes the\nGuggenheim\u2019s workflow for disk imaging.<\/p>\n\n\n\n

There\nare currently no widely agreed-upon strategies for archiving the components of\ncomputer- and software-based artworks. This article aims to contribute to the\nongoing research and development of such strategies. As conserving\ncomputer-based artworks is a rapidly evolving field, these are preliminary\nfindings. The article concludes with a set of preliminary recommendations for\ncomponents to collect when acquiring computer- and software-based artworks.<\/p>\n\n\n\n

Archiving\nsoftware- and computer-based works varies for different artworks and translates\ninto flexible and multipronged preservation strategies. With computer-based\nartwork, collecting the components and information for preservation as soon as\npossible is essential, as they may become much harder or impossible to collect\nin the future. As Serexhe and others have observed, \u201coften it is only when the\nworks are to be presented again that data loss and incompatibility with current\nhardware and software are discovered\u201d (Serexhe 2013, 83). Exhibition or\nacquisition may constitute the only opportunities for the conservator to\nobserve or document the artwork running according to the artist\u2019s\nspecifications. Thus, creating documentation of the artwork through video,\naudio, still images, or other means will prove critically important as\nreference material later. <\/p>\n\n\n\n

Archiving\nthe components of a computer-based artwork means first analyzing all hardware\nand software involved. As with any time-based media work, this is a critical\nstep to \u201cidentify the meaning and work-defining properties of the artwork\u2019s\nconstituent parts, as well as the work\u2019s aesthetic or conceptual dependence on\ncertain devices or technologies\u201d (Phillips n.d.). This analysis enables the\nconservator to ask the right questions concerning future preservation of the\nwork, though the answers are often artwork dependent.<\/p>\n\n\n\n

Any archiving strategies must address this question: \u201cWhat \u2018resources\u2019 are necessary to sustain the artwork?\u201d In other words, what files, hardware, reference materials, and information will be needed to effectively steward this artwork into the future? These considerations involve not just creating a copy of the appropriate data but also considering what information may be needed for future treatments of the artwork, such as migrating code to another programming language or running the artwork within an emulator or virtual machine (software that mimics a different computing environment, usually an older\/obsolete computer or operating system).<\/p>\n\n\n\n

PHYSICAL COMPONENTS<\/h2>\n\n\n\n

Through\nits acquisitions of computer- and software-based artworks, the Guggenheim has\nreceived a variety of computers and microcontroller units from artists. This\nartist-provided equipment typically contains the software that runs the\nartwork.<\/p>\n\n\n\n

The status of physical equipment in a collection depends on its significance for the artwork (Laurenson 2004; Phillips 2012). Artists often provide their own equipment to run these artworks for a variety of reasons; some works employ unique, dedicated equipment. For his work entitled Color Panel <\/em>(1999), John F. Simon Jr. (b. 1963) custom-modified an Apple Powerbook 280c laptop (fig. 1). In other cases of dedicated equipment, an artist may use unmodified computer hardware, though its appearance may be integral to the artwork.<\/p>\n\n\n\n

\"Fig.
Fig. 1. Image of John F. Simon Jr.\u2019s Color Panel (1999), an artwork that employs an artist-modified Apple Powerbook 280c laptop. Courtesy of the Solomon R. Guggenheim Museum.<\/figcaption><\/figure>\n\n\n\n

In\nother cases, the hardware may not be dedicated, but the artist may still\nprovide it. The artwork may require specific hardware and software properties\nand settings; the artist may decide to independently source the equipment for\nconvenience or the artist may provide off-the-shelf hardware to a museum in\norder to simplify installation (so that the piece can simply be plugged in and\nturned on).<\/p>\n\n\n\n

Computers\nprovided by artists are often consumer-grade models (such as the two HP\nPavilion 8140 computers included with an artwork acquired in 2001) and were\nnever intended by the manufacturer to last for more than a few years. While\nthis equipment is functioning and still available to examine, gathering\ninformation about the hardware and software configuration of these computers,\nas well as any connected devices or peripherals, will prove useful to sustain\nthe artwork. In the future, it may be necessary or desirable to replace\nnondedicated hardware with equipment that shares the same or a similar\nconfiguration.<\/p>\n\n\n\n

An\nartwork may also be run independently of the original hardware using a disk\nimage running in an emulator or virtual machine. Gathering information about\nthe hardware, software, and connected devices gives future conservators a\nreference for choosing the proper settings. For example, in an artwork that\nuses a serial port to send signals to a projector, this type of connection must\nbe set up in the emulator or virtual machine for the artwork to function\nproperly. In addition, the specific hardware and software configurations used\nfor the work may have aesthetic or conceptual significance or reveal the\nartist\u2019s working methods, which may affect future art historical literature\nrelated to the artist or artwork.<\/p>\n\n\n\n

The\nspecifications of a computer can have a direct impact on the aesthetic\nproperties and behavior of an artwork. For example, the clock speed of the central\nprocessing unit (CPU) can determine the speed at which an artwork runs. After\nNYU Computer Science student Xincheng Huang analyzed the source code of Color Panel<\/em> (1999), he discovered that\nthe artist did not specify a frame rate in the code. Therefore, the speed at\nwhich Simon\u2019s program animates its changing color patterns depends on the clock\nspeed of the CPU running the artwork.<\/p>\n\n\n\n

While\nthe artwork is still functioning, reference video, screen captures, or still\nimages can be created to illustrate the work\u2019s behaviors. This documentation of\nthe native display environment gives future conservators another point of\nreference to guide any future migration or re-creation of the artwork. For\nexample, video documentation of the original work running can be compared to\nthe work running under emulation or virtualization.<\/p>\n\n\n\n

There\nis an incredible breadth of technical information that can be generated about\nthe hardware and software of a single computer, but it is unclear at this time\nexactly which information is critical to obtain if the museum chooses to run\nthe artwork on another computer or in an emulator or virtual machine. A list of\nminimum information to gather about computer equipment and its configuration is\nstill very much in development. The following findings are preliminary and\ndeserve further research and discussion but may provide some guidance.<\/p>\n\n\n\n

By\nexamining the manufacturer\u2019s box or the computer\u2019s external case, one can\nrecord the serial number and model number of the machine. The serial number can\nprovide a unique identifier for the computer. It may also indicate when the\nmachine was manufactured. The model number can also be cross-referenced to a\nspecific configuration. Without switching the computer on, one can document the\navailable ports on the computer and any PCI\/PCIe cards installed. These ports\nor cards may be used to attach peripherals that the artwork uses, such as video\nmonitors, audio interfaces, or additional hard drives. This information can be\ncaptured through photos. By opening up the computer\u2019s case, it may be possible\nto determine the model of the CPU, the amount of random access memory (RAM),\nand the model of graphics processing unit (GPU or graphics card) used in the\ncomputer.<\/p>\n\n\n\n

If booting up the artwork\u2019s computer is possible, much more detailed information can be obtained. Computers running the Windows, Linux, and Mac OS operating systems have built-in software to export extremely detailed information about their hardware and software configurations. In Mac OS, the program \u201cSystem Report\u201d can export this information as an .spx file (fig. 2). <\/p>\n\n\n\n

\"Fig.
Fig. 2. A small section of the contents of a Mac OS .spx file that lists the CPU, amount of RAM, and the computer serial number, among other information. Courtesy of the Solomon R. Guggenheim Museum.<\/figcaption><\/figure>\n\n\n\n

Within this file, information about the computer is encoded in the eXtensible Markup Language (XML) format. This includes details about the CPU, GPU, and RAM, which programs and drivers are installed, and even any devices that are connected to the computer at the time that the report is exported. In most versions of Windows, running the command \u201cmsinfo32\u201d can produce similar results. The user can save an .nfo file, which is also XML encoded. In Debian Linux (and its popular variant Ubuntu) the program \u201chardinfo\u201d also collects similar information, which can be exported to an HTML file and converted to XML if desired in the future. These types of files have been created when examining computers as part of the CCBA survey and backup, and the process of exporting software and hardware configuration information has been integrated into the Guggenheim\u2019s disk imaging workflow.<\/p>\n\n\n\n

Several artworks in the Guggenheim\u2019s collection use microcontroller units, custom built by the artist or the artist\u2019s technician. A microcontroller unit is a small programmable microprocessor that runs a single program. Several microcontroller platforms have been popular among artists, including PIC, BASIC Stamp, and Arduino. Microcontrollers are often used to automate a physical process within a complex installation work, such as starting or stopping conveyor belts and fans at specific times, as in Phoebe Washburn\u2019s Regulated Fool\u2019s Milk Meadow<\/em> (2007; fig. 3) or to choreograph the movements of motorized objects covered by gunny sacks, as in Susanta Mandal\u2019s Caged Sacks <\/em>(2007\u20132008).<\/p>\n\n\n\n

\"Fig.
Fig. 3: The microcontroller unit used for Phoebe Washburn\u2019s Regulated Fool\u2019s Milk Meadow (2007). This microcontroller runs code that controls conveyor belts, fans, and watering mechanisms within the installation. Courtesy of the Solomon R. Guggenheim Museum.<\/figcaption><\/figure>\n\n\n\n

With works that employ microcontrollers, understanding each of the microcontroller\u2019s pin connections is essential to making sense of the artwork\u2019s code and ultimately determining how the piece functions. In many cases, the result of the code running on the microcontroller is that an electrical current is sent through a specific pin to turn a piece of physical equipment (such as a conveyor belt of a fan) on or off. Some pins on microcontroller units are also input pins and may receive signals from physical equipment, such as motion sensors or light sensors.<\/p>\n\n\n\n

INFORMATION CARRIERS<\/h2>\n\n\n\n

Artists\nalso provide the museum with software and files on a variety of information\ncarriers. Stored on these information carriers are source code files,\nexecutable files, project files, backups of related files, and, occasionally,\ndisk images. Computers themselves contain an information carrier, an internal\nhard drive.<\/p>\n\n\n\n

Internal and external hard drives, floppy disks, and optical disks are not sustainable information carriers\u2014particularly optical media (Byers 2003; Owens 2014). The time of physical failure for these items is unpredictable; often, technological obsolescence will precede physical breakdown. While there has been little long-term research on the longevity of hard drives, a study produced by cloud storage provider Backblaze of more than 25,000 hard drives has shown that drives experience an 11.8% failure rate over the first four years of the drive\u2019s life. A study by Gibson and Schroeder found that in large IT installations, annual failure rates \u201ctypically exceed 1%, with 2-4% [being] common\u201d (2007, 1). Thus, data should be copied off of these information carriers as soon as possible, before they become unreadable (McKinley 2013). The ideal site for the extracted data is dedicated archival storage, also known as a trusted digital repository (Online Computer Library Center et al. 2007). Fortunately, conservation staff at the Guggenheim have not come across media that are entirely unreadable. However, in the course of the CCBA survey and backup, some older hard drives were found to contain \u201cbad sectors\u201d\u2014areas of the drive that are no longer readable or writable due to physical damage or deterioration.<\/p>\n\n\n\n

DIGITAL ARTWORK ASSETS<\/h2>\n\n\n\n

Contained on the physical carriers that the museum collects\nare the digital artwork assets. A short description of each category of assets\nfollows.<\/p>\n\n\n\n

Source Code<\/em><\/p>\n\n\n\n

Source code is the instructions of a computer program originally written by the artist or the artist\u2019s technician). For new acquisitions, the Guggenheim always attempts to collect the source code of a computer-based artwork. Source code is written in high-level programming or scripting languages such as Python, C, or ASP (fig. 4). <\/p>\n\n\n\n

\"Fig.
Fig. 4: Screenshot of source code written in ASP for Siebren Versteeg\u2019s Untitled Film II (2004). The code also includes artist-written comments. Courtesy of the Solomon R. Guggenheim Museum.<\/figcaption><\/figure>\n\n\n\n

Source code is human readable if one understands the programming language; analyzing the source code allows conservators to understand the behaviors of an artwork, which shapes future conservation decisions (Engel and Wharton 2014). Previous research has concluded that \u201ctechnical research on artist-generated source code not only serves conservation, but it can also aid art-historical research on artists\u2019 aesthetic aims and their working methods\u201d (Engel and Wharton 2015, 91). Without understanding the code, conservators may not be able to make informed decisions about future preservation strategies or treatment.<\/p>\n\n\n\n

During\nacquisition, source code is delivered to the museum as one or more digital\nfiles that can be opened in a text editor, not as a PDF or as a hard copy\nprintout. It is sometimes overlooked that microcontroller units run code as\nwell and the source code may need to be requested separately during\nacquisition.<\/p>\n\n\n\n

Project Files<\/em><\/p>\n\n\n\n

Computer-based artworks written in proprietary development environments such as Adobe Flash, Macromedia Director, or Max MSP do not have source code in the traditional sense (though these development environments sometimes have integrated scripting languages in which code can be added). These are primarily visual programming languages in which a user creates a project and can manipulate elements in a timeline to create a sequence of events or connects various virtual modules to create a logical flow (fig. 5). <\/p>\n\n\n\n

\"Fig.
Fig. 5: Screenshot of the Max MSP project (also called a patcher) for Doug Wheeler\u2019s PSAD Synthetic Desert III (1971\/2017). Courtesy of the Solomon R. Guggenheim Museum.<\/figcaption><\/figure>\n\n\n\n

In these cases, the Guggenheim collects the original project file for the artwork, as this is equivalent to the source code for these development environments.<\/p>\n\n\n\n

Software\nLibraries and Plug-ins<\/em><\/p>\n\n\n\n

Whatever\nprogramming language or development environment was used, an additional\nconsideration is whether software libraries or plug-ins were used in the\nartwork. Libraries are collections of files with prewritten code that handle\ncommonly used routines and make writing new code easier. If a programmer uses a\nlibrary, it may be necessary to have a complete copy of the entire library in\norder for the original source code to run or compile properly. In this case,\nthe library becomes a \u201csoftware dependency,\u201d a necessity for the artwork to\nfunction. Plug-ins are used in development environments such as Macromedia\nDirector, Adobe Flash, or Max MSP. These additional files add functionality\nthat is not included in the environment by default. Plug-ins may be\ndependencies for a project file to open correctly. In the case of Max MSP, in\nwhich artworks are often run via the project, the plug-in would be necessary to\nexhibit the work. In Doug Wheeler\u2019s PSAD\nSynthetic Desert III<\/em> (1971, realized 2017), which uses Max MSP to generate\na soundscape for the piece in real time, a plug-in called \u201cSpatialisateur\u201d is\nused to randomly delay sending audio to different speakers throughout the art\nspace.<\/p>\n\n\n\n

For\nInternet-connected artworks, libraries are sometimes called from a separate\nwebsite. If the website that maintains the library ceases to exist, then the\nartwork may not function. This issue can be mitigated by collecting a full copy\nof the library or placing it inside the code base. In the restoration of the\nGuggenheim\u2019s web artwork Brandon <\/em>by\nShu Lea Cheang (b. 1954), the JQuery library was used. A full copy of this\nlibrary was placed in all of the areas of the site where it was used.<\/p>\n\n\n\n

During\nacquisition, the artist or the artist\u2019s technician might not always think about\nincluding libraries when transferring source code or project files to a museum.\nIdentifying the necessary libraries or plug-ins at the outset of collecting a\ncomputer-based artwork helps ensure that the museum obtains all of the\nartwork\u2019s software dependencies.<\/p>\n\n\n\n

Executable\nFiles<\/em><\/p>\n\n\n\n

Exhibition\ncopies of software-based artworks are often delivered as executable files. The\nexecutable simplifies the process of starting the artwork\u2014the executable can\nsimply be clicked or it can be set to autostart when the computer starts.\nCreating an executable file also eliminates the need to have certain software\ninstalled on the computer running the artwork. For example, executable files\nare created for Adobe Flash projects so that the computer does not need a full\nversion of Adobe Flash installed. Windows executable files typically have the file\nextension .exe and executables on Mac OS have the extension .app.<\/p>\n\n\n\n

To\ncreate executable files, source code or a project file is typically compiled,\nturning it into either binary code or a lower-level programming language and\nmaking it unreadable to humans. Thus, the executable often exists as a \u201cblack\nbox\u201d; in this form, it is impossible to analyze its specific logic and\nbehaviors. Even if the executable file is collected, the Guggenheim collects\nthe source code or project files as well. Unlike the executable file, the\nsource code or project file allows for analysis of the artwork\u2019s behaviors.<\/p>\n\n\n\n

Related\nMedia Assets<\/em><\/p>\n\n\n\n

The programs behind computer-based artworks often make use of audio files, video files, or still image files. These media assets are also collected as part of the acquisition. Depending on the situation, they may also need to be extracted from project files or separate file directories. The Guggenheim collects these files in the event that they need to be used in any future migration or reconstruction of the work. <\/p>\n\n\n\n

MUSEUM-CREATED DIGITAL ASSETS<\/h2>\n\n\n\n

Guggenheim\nstaff also creates digital assets related to computer-based artworks. These\nfiles also require archiving. For example, as part of the Guggenheim\u2019s ongoing\ncollaboration with New York University\u2019s Department of Computer Science, the\ndepartment\u2019s students conduct source code analysis of artworks. As part of the\nanalysis, the students often annotate the code with detailed descriptions of\nhow it functions. In addition to the original source code, these annotated\ncopies of the source code are tracked and saved as reference material along\nwith other components of the artwork.<\/p>\n\n\n\n

In\nthe past, research partners at NYU have decompiled code in order to analyze it\nbecause the original source code for an artwork was not accessible at the time.\nDecompilation means turning a compiled executable file into readable source code.\nHowever, there is a significant loss of information in decompiled code\u2014the best\nsource for analysis remains the original source code (Engel and Phillips forthcoming).\nNevertheless, copies of decompiled and annotated code have been archived as\nreference material for artworks.<\/p>\n\n\n\n

The\nGuggenheim has engaged in two restorations of web artworks that used the\nstrategy of code migration: Brandon<\/em>\nand John F. Simon Jr.\u2019s Unfolding Object<\/em>.1<\/sup>\nTherefore, a new restoration version of the fileset was created and this restoration\nversion was archived as a separate component of the artwork.<\/p>\n\n\n\n

Conservation\nstaff also creates a variety of preservation elements, including web archives\n(which provide an interactive historical record of the appearance and behavior\nof web artworks), transcoded files, and disk images.<\/p>\n\n\n\n

Transcoding<\/em><\/p>\n\n\n\n

Files\nin obsolete or obscure formats require transcoding, which means taking the\ncontent of a given file and translating it into a different format, usually for\naccess or preservation purposes. For example, during the restoration of Brandon<\/em>, audio files in the now-obsolete\ncompressed format Real Media audio were transcoded to the WAV format, which is\nuncompressed and regarded as the \u201cde facto standard for digital archival audio\u201d\nby the Association of Recorded Sound Collections and the Library of Congress\n(Brylawski et al. 2015, 111). In the case of another artwork, Color Panel<\/em>, an Apple image file that\ncould be opened only in older versions of Photoshop was transcoded to TIFF, an\nuncompressed format. Even if transcoding occurs, the original file is always\nkept. Transcoding is never meant to replace the original but rather to prevent\nits content from becoming inaccessible in the future.<\/p>\n\n\n\n

Disk\nImages and Web Server Images<\/em><\/p>\n\n\n\n

Creating\na disk image is currently the best strategy for archiving the information on a\nhard drive, floppy disk, or optical disc. As mentioned previously, physical\ninformation carriers such as hard drives and disks are quite vulnerable.\nCreating a disk image is the most effective method for providing a\ncomprehensive backup of all data contained on a physical carrier. The contents\nof the carrier are written to a single file (the disk image), which cannot be\neasily modified. With forensic disk image formats, such as E01, metadata can be\nembedded in the disk image file and this metadata can be connected to the\nitem\u2019s record in a collection management system or inventory. Disk-imaging\nsoftware reads the entire physical area of the storage device. Therefore, in\naddition to all the files intentionally saved, the disk image can also contain\ndeleted files and unused empty space on the storage device.<\/p>\n\n\n\n

In order to create a disk image of an internal hard drive, it often must be physically removed from the computer\u2019s case. The drive is then connected to a write blocker, also known as a forensic bridge (fig. 6). <\/p>\n\n\n\n

\"Fig.
Fig. 6: An overview of the disk imaging process for a hard drive that illustrates the use of a write blocker. Courtesy of the Solomon R. Guggenheim Museum.<\/figcaption><\/figure>\n\n\n\n

The write blocker prevents the computer that is creating the disk image from ever writing to or altering any data on the drive or disk while it is being imaged by either creating hidden files or altering the metadata of existing files. Write blockers are used by criminal investigators in the field of digital forensics, who must prove that the data they obtained was not altered in any way. Hardware write blockers in use by the digital forensics community are tested by the National Institute for Standards and Technology (NIST) to ensure that they will not write to any connected storage media (Allen 2017). These include write blockers manufactured by Wiebetech and Tableau that are in use in the Guggenheim media lab.<\/p>\n\n\n\n

If\na write blocker is unavailable, some floppy disks have their own form of write\nprotection built into the disk itself via a plastic slider. Optical discs do\nnot require write blocking because they are typically \u201cread only\u201d storage\nmedia. Even if rewritable discs like CD-RW or DVD-RW are being imaged, an\nexaminer would need to take several intentional steps to write data to them,\nwhereas with hard drives, the automated processes of the connected computer\ncould create files or alter metadata.<\/p>\n\n\n\n

The Guggenheim\u2019s three web artworks exist on a virtualized web server hosted by a cloud service provider. For the restoration of Brandon<\/em>, the conservation department collected a virtual disk image of the web server in order to preserve the pre-restoration version of the artwork. The Guggenheim\u2019s cloud service provider had the option to export a virtual hard drive (VHD) from the museum\u2019s virtual server. While it may not be possible to start up an instance of this server again outside of the cloud provider (owing to proprietary settings) the web server image still serves as a valuable historical snapshot of the artwork and the server settings.<\/p>\n\n\n\n

DISK IMAGING WORKFLOW<\/h2>\n\n\n\n

As part of the CCBA initiative, a workflow was developed for disk imaging (fig. 7). <\/p>\n\n\n\n

\"Fig.
Fig. 7: A visual overview of the steps of the Guggenheim\u2019s disk imaging workflow. Courtesy of the Solomon R. Guggenheim Museum.<\/figcaption><\/figure>\n\n\n\n

This procedure is based on research of the workflows used by libraries and archives (Gengenbach 2012), including workflows used by the Guggenheim\u2019s Library and Archives, other museum workflows (such as the Denver Art Museum), and experience in the Guggenheim media lab. The workflow benefited significantly from the Guggenheim\u2019s participation in the December 2017 Museum of Modern Art\u2019s Peer Forum on Disk Imaging and advice from colleagues in conservation and libraries and archives.2<\/sup> The workflow differs for hard drives, optical discs, and floppy disks. SD cards and USB flash drives are treated similarly to hard drives in the workflow.<\/p>\n\n\n\n

Pre-Imaging\nDocumentation<\/em><\/p>\n\n\n\n

Every\nitem being imaged goes through a pre-imaging stage in which documentation about\nthe physical media is collected. Conservators take check-in photos of the item,\nincluding any connectors and labels, and gather technical information,\nincluding its capacity, physical size, serial number, model name, and model number.\nThis information is entered into a disk imaging report that is completed for\neach image. If the hard drive was inside of a computer, staff collects\ninformation about the configuration of the computer (using procedures detailed\nin the earlier \u201cPhysical Components\u201d section of this article) during this stage\nas well.<\/p>\n\n\n\n

Creation\nof Disk Image<\/em><\/p>\n\n\n\n

With\nthe initial documentation of the storage device and the computer completed, the\ndisk image can then be created. Information about how the disk image was\ncreated gets recorded in a disk imaging report, for example, which forensic\nbridge was used, and which adapters were used.<\/p>\n\n\n\n

There\nare several file formats to consider for disk images, but these formats\ngenerally fall into two broad categories: forensic disk images and raw disk\nimages. Forensic disk images allow technical and descriptive metadata (including\nseveral fields that an institution call fill out in any way they choose) to be\nembedded in the disk image itself. Forensic images can also compress the data.\nThey are efficient at compressing empty space on a hard drive. Forensic images\nalso create cyclic redundancy checks (CRC32s), which validate that every sector\nof the hard drive has been copied accurately in the disk image.<\/p>\n\n\n\n

The\nleading candidate for a forensic image format appears to be E01, also known as\nthe EnCase format, based on both widespread adoption by professionals in\nlibraries and archives and current support by a wide range of software\n(AVPreserve 2016; Knight 2011).  However,\nwith E01 files and all other forensic images, specific programs or libraries\nthat interpret the forensic file format are needed to open them. Whether these\ntools for opening E01 files will continue to be supported in the future raises\nquestions about the sustainability of the format. As the forensics community\ncreates new formats, it becomes unclear whether older formats will be\nsupported.<\/p>\n\n\n\n

A\nraw image is simply a sector-by-sector copy of all data on a hard drive with no\nmetadata wrapper and no compression. Therefore, a raw disk image of a 1TB hard\ndrive will be exactly 1TB regardless of how many files were actually stored on\nthe drive. This also means that raw images do not require any interpretation or\ndecompression in order to be read. The file is simply a raw stream of all of\nthe data from the device being imaged.<\/p>\n\n\n\n

In\nthe Guggenheim\u2019s workflow, a disk image is first created in the E01 format.\nThen a raw image is exported from the E01 file. Creating the raw image is an\nextra preservation measure should support for E01 disk images no longer be\navailable.<\/p>\n\n\n\n

Disk\nImage QC<\/em><\/p>\n\n\n\n

After\ncreating a disk image, some degree of quality control (QC) inspection must take\nplace to ensure that the disk image is an accurate copy of the data and is\nuseful in the future. As the disk image is being created, most imaging programs\n(such as FTK Imager and Guymager) automatically check for bad sectors on the\ndrive. These are areas of physical damage to the drive, where the imaging\nprogram was not able to extract data. If a drive has bad sectors, it may need\nto be read with a program such as GNU ddrescue, which can perform multiple\npasses on the drive to extract data. The presence of bad sectors may indicate\nthat the drive is failing (Hoffman 2013).<\/p>\n\n\n\n

Methods also exist to verify that the disk image is a bit-for-bit copy of a storage device. Most imaging programs perform automatic verification of the image\u2014ensuring that the data of the disk image and the data on the physical information carrier are absolutely identical. The imaging programs verify the image (which can also be done manually) by comparing checksums. A checksum is any extremely unique alphanumeric value produced by running a complex mathematical algorithm through all of the bits that constitute a file or storage device. A checksum is sometimes called a \u201cdigital fingerprint,\u201d but checksum algorithms create values that are much more unique than fingerprints. For example, the popular checksum algorithm Message Digest 5 (MD5) consists of a 32-digit hexadecimal value, meaning that there are 1632<\/sup> theoretically possible checksum values (fig. 8). <\/p>\n\n\n\n

\"Fig.
Fig. 8: A screenshot of running the command \u201cmd5\u201d in the Mac OS terminal, which produces an MD5 checksum for a file. The checksum value is displayed on the last line. Courtesy of the Solomon R. Guggenheim Museum.<\/figcaption><\/figure>\n\n\n\n

Due to avalanche effects in the calculation of the checksum, even a single change in one bit of a file will result in producing a radically different checksum (Wikipedia 2018). If the storage device being imaged and the disk image file produce the same checksum, then the image is considered verified.<\/p>\n\n\n\n

As\npart of the QC stage in the Guggenheim\u2019s workflow, ensuring that the images are\naccessible is also important. Three tests were devised to determine the level\nof accessibility. First, the disk image is opened in FTK Imager or Bitcurator\u2019s\nDisk Image Access Interface. The partitions are examined to make sure that they\nmatch those of the original drive or disk. This check is completed in order to\nprevent a situation encountered by Rechert and von Suchodoletz (2015) in which imaging\nappeared successful but the disk image did not produce the proper partition\nlisting.<\/p>\n\n\n\n

If\nthe image passes the previous test, files are exported from it. If exporting\nfiles is successful, the image passes the second stage of QC. If the disk image\nis of a hard drive containing an operating system, the third step is an attempt\nto run the image in an emulator or virtual machine. If the image is of an\noptical disk or a floppy disk, mounting the image on different operating\nsystems is attempted at this stage. The results are recorded in the disk imaging\nreport, including any settings that were modified in the emulator or virtual\nmachine. At this point in the CCBA research being conducted, the image not\nrunning in an emulator or virtual machine is not grounds to fail QC. The\nresults are simply noted, and staff may return to the image at a later date to\ndetermine why it did not run.<\/p>\n\n\n\n

Disk\nImage Analysis and Transfer<\/em><\/p>\n\n\n\n

After\nQC is complete, analysis of the contents of the image can be conducted. The\ngoal of this stage is to generate a Digital Forensics XML (or DFXML) file for\nthe contents of the image. DFXML is a standard used to record metadata about a\ngroup of files or an entire disk image in XML format. It was created by the digital\nforensics community and later adapted by librarians, archivists, and\nconservators. Digital preservation software such as Archivematica has DFXML\ncreation built in as a microservice but creating DFXML files can also be done\nvia the command line or through the Bitcurator suite\u2019s reports module.<\/p>\n\n\n\n

Two\nprograms capable of creating DFXML files are Hashdeep and Fiwalk. Hashdeep\ntraverses file directories and can output DFXML for all files and folders\ncontained within a given directory. Fiwalk (or Filesystem Walk) is used for\ntraversing and analyzing the entire file system of a disk image. However,\nFiwalk cannot handle all file systems, such as the classic Mac file system HFS\n(Hierarchical File System), used on all versions of Mac OS before OS 8.1\n(released in 1998).<\/p>\n\n\n\n

For a single file, a DFXML record contains a wealth of information, such as the full path to the file (which includes the filename) as well as MD5 and SHA1 checksums for the file (fig. 9). <\/p>\n\n\n\n

\"Fig.
Fig. 9: The DFXML record for one file in a disk image. Line 87293 shows the path to the file. Lines 87313 and 87314 show checksums computed for the file. Lines 87305 to 87308 show the timestamp metadata, and line 87309 shows the file format identification. Courtesy of the Solomon R. Guggenheim Museum.<\/figcaption><\/figure>\n\n\n\n

The DFXML file also contains file format identification, such as whether the file is a text document or a GIF image, through checking for the \u201cMagic Number\u201d of a file. The Magic Number is an alphanumeric signature of the file type that is usually found within the first few bytes of the file.<\/p>\n\n\n\n

Going\nthrough an analysis step for a disk image has several benefits. It creates a\nmachine-readable inventory of every file in the image, including its checksum,\nmetadata, and file format. The checksum can be used to ensure that any files\nexported from the image are exact copies. File metadata may be used as one\npoint of reference to glean the last time that the file was modified. File\nformat identification may also help staff get a clearer picture of the threatened\nor already obsolete file formats in their collections that may need to be\ntranscoded.<\/p>\n\n\n\n

DFXML\ncontains timestamp metadata for the file, including the last modified time\n(Mtime), last changed time (Ctime), and added time (Atime). However, digital forensics\npractitioners are skeptical about using this metadata to construct a narrative\ntimeline of events because it can be altered easily, and its meaning is not\nalways intuitive. They suggest gathering additional evidence to corroborate the\ntimes and dates found in file timestamp metadata (Manes n.d.; Whitfield n.d.).\nIn general, Mtime is considered the most reliable because it is the hardest\nfield to change (Woods 2018). Some file systems, such as those used for Mac OS\nand Windows, also record a \u201ccreation\u201d or \u201cbirth\u201d time for the file. Though it\nmay seem as if this timestamp indicates when the file was originally created,\nit is highly deceptive. If a file on a Mac is later copied to a Windows\ncomputer, the creation time can be altered to the date that the file was copied\nto the second computer; thus, the creation time does not necessarily reflect\nwhen the file was first created.<\/p>\n\n\n\n

Timestamp\nmetadata is heavily dependent on the file system; moving a file from one file system\nto another can cause the timestamp to change. Disk imaging creates\nencapsulation so that timestamps are always intact, but creating disk images\nfor all components of a computer-based artwork that a museum receives is not\nalways possible. For example, if the artist emails conservators a ZIP file, a\ndisk image cannot be created.<\/p>\n\n\n\n

When\nanalysis is complete, the disk imaging report is completed, which marks the end\nof the disk imaging workflow. A document detailing all of the steps of this\nworkflow will be available on a forthcoming CCBA webpage on the Guggenheim\u2019s\nwebsite.<\/p>\n\n\n\n

Following QC and the completion of the disk imaging report, the next step is transferring the disk image from the disk imaging computer workstation to the museum\u2019s server storage for artworks. Whenever a transfer occurs, one must verify that the new copy is an exact duplicate of the original and no file corruption occurred during the transfer. The Guggenheim uses the program Bagit to ensure that transfers to the server are free of corruption. The program uses a Library of Congress standard for file transfer aptly called a \u201cbag.\u201d Bagit packages the files in a standardized structure and creates a manifest with checksum values for all files contained inside the bag. The contents of the bag can then be verified before and after transfer and at any point later.<\/p>\n\n\n\n

CATALOGING AND TRACKING<\/h2>\n\n\n\n

With\nso many types of files and file derivatives, tracking all elements of these\nartworks quickly becomes complex. Many of the challenges in managing\ninformation when collecting computer-based art are similar to cataloging and\ndescribing video art. For example, when cataloging these works, one must\nconsider both physical information carriers and their contents. Like video art,\ncomputer-based artworks often have different versions and the differences\nbetween them may be extremely subtle. The complex relationships between\ndifferent components must be understood and documented as well. An artwork may\nmake use of multiple computers that all run different code and serve different functions,\nwhich makes accurate cataloging and tracking critical.<\/p>\n\n\n\n

When\ncataloging computer-based art, the Guggenheim uses the same status hierarchy as\nwith other time-based media artworks. Three general statuses exist for\ncomponents: \u201cartist-created or provided,\u201d \u201cmuseum-created,\u201d and \u201cresearch\nmaterial.\u201d In addition, every version of an artwork gets a separate set of\ncomponent numbers. The version and date for each component is described as well\nas the relationships to other components, and information about how the\ncomponent was created is recorded if applicable. The Guggenheim uses The Museum\nSystem (TMS) to track components, but many institutions use this same database\nin different ways. For example, the Inter Media Art Institute Foundation in\nDusseldorf adapted TMS to describe the relationships between videotapes and the\nvideo files that were the result of digitization (Kumura-Myokam 2018). Such a\nsystem could be adapted for cataloging the components of computer-based\nartworks.<\/p>\n\n\n\n

Extensive\ndocumentation about each artwork, created by conservators, is kept in the\nmuseum\u2019s digital object file. This documentation includes recordings of\ninterviews with artists and their technicians, installation instructions, identity\nand iteration reports, narrated screen recordings of artworks running,\ntreatment reports, schematics of artworks, and flowcharts and site maps related\nto works. These files are kept on a separate server from files considered\nartwork, as the object file is frequently being revised and added to.<\/p>\n\n\n\n

RECOMMENDED ASSETS FOR ACQUISITION<\/h2>\n\n\n\n

Currently,\nthere are no widely agreed-upon procedures to guide conservators and curators\nin the acquisition of computer-based artworks. All museums can stand to improve\ntheir acquisition practices for these artworks, including the Guggenheim.\nDeliverables for acquisition will vary considerably depending on the artwork\nand which technologies were employed. A conservator will ask for different\ncomponents for a Python script that scours the Internet for data versus a Flash\nanimation that contains multiple image and audio assets.<\/p>\n\n\n\n

Through\nthe CCBA initiative, the Guggenheim has gained additional experience in the\nacquisition of computer-based artworks and would like to offer this list of\nrecommended assets for acquisition as a means to contribute to the continued\ndialogue around acquiring computer-based artworks. However, the field is under\nconstant development and these recommendations are preliminary:<\/p>\n\n\n\n