This document outlines a proposed net art project called "digital demise" that aims to track and document the destruction caused by hackers on a server. The project will monitor hackers' actions on the server, retrieve the data, and use it to dynamically generate graphic content on a separate website. It discusses the technical components, influences, aesthetics, planning, testing, and potential shortcomings of the project.

1. digital demise A proposed net_art project by: robin turner_brad bennie_david pope_a modified dog

2. digital demise _the collaboration robin turner_a digital arts student responsible for_project co-ordination, design, research and programming brad bennie_a seasoned interactive designer Will be acting as a consultant programmer and Linux (server) expert david pope_is a programmer and web host he is our network specialist A modified dog_is an action script god that lives in online forums. he trouble shoots code issues, and makes rob feel inadequate

3. digital demise _conceptual statement This project aims to track the destruction caused by hackers in the digital domain. As hackers abuse my server, warehouse the hardrive and tamper with the system settings, their actions are monitored, retrieved and delivered to a remote web server where their secretive doings affect the graphic content of and are broadcast through a peripheral website.

4. digital demise _conceptual statement Whilst this project aims to satirize the nature of hackers (like a thief robbing from the Big Brother or Survivor set), it also deals with two other important key issues: It aims to document what could potentially be an undocumentable subject matter, as well as look at the nature of life or creativity and death in virtual space as a means of creating from destruction: In death and destruction, beauty and life (or creativity) may exist, for the life of the website is dependant on the death of the server… (a parallel metaphor to the parasitic nature of hackers)…

5. digital demise _conceptual statement Hackers like to make folders. They fill these folders with illegal software, cracks, porn, movies and mp3’s. They throw the odd virus in to boot. They leave notes and messages for each other in folder descriptors. They tinker with systems files, and the malicious ones aim to take hardware down. PC format once set up a brand new machine, took the security off, plugged it into the network, and promptly had to reformat it 19 seconds later.

6. digital demise _the components A server will be required. This will be the warehouse that the hacker will use to store uploaded files. David Pope had a server hacked… the hackers over shot his ADSL cap limit by 2 terabytes. They also installed virus’s which act like bots. These probe the server and alert the hacker if the machine is a potentially useable warehouse. Because this server will be designed to be destroyed (all securities and permissions will be laxed), the web site must be hosted on a second server, and the primary server must be totally isolated from any other network for security reasons. The components therefore will consist of a primary server, a secondary web server, a dynamic dns, and an uncapped ADSL line.

8. digital demise _the creative influences In 1995 Gregg Shaw tracked the amount of attempted hacks on his personal computer. Hacking Statistics is the main feature of his website at the moment, providing various statistics, graphs and tables on unauthorised Internet access to his computer over the period of a year. http://www.btinternet.com/~shawweb/george/

9. digital demise _the technical influences I found inspiration in Golan Levin's “the dumpster project”. I like the way that the technology populates the website itself, that the website seems alive as it sends its little bots out to find and retrieve personal information, to feed itself. Like the Dumpsters approach to documenting the similarities and differences between failed relationships, and allowing these to affect the look of the interface, I aim to document and track live hacker activity, and get them to create without them even knowing it.

11. digital demise _the technical influences I find I/O/D’s interface design of particular interest. Whilst I find their approach to web page interfacing of particular importance, I found myself particularly interested in the aesthetic of self generated imagery determined by the software. This is in line with my interpretation of code tracking, and the logging of this to affect the cosmetic qualities of objects (a web site in this case).

13. digital demise _aesthetics Because the site deals with destruction and creativity, and life and death, so the cosmetic or aesthetic approach to the layout of the site looks to mimic an obituary page in a newspaper. As the log file entries created by the server track and record activity (anything from the creation of new folders, to the tampering of security settings), they are presented as columns of obituary entries. The log files and paper clippings share common traits, such as dates, names, know activities, and possibly imagery) The document will search for keywords within the log entry, words such as error, will effect the colour of the entries movie clip, and add relevant phrases to the movie clip (such as: we will miss him dearly) Current thoughts around the presentation of the levels of activity. Automatic system entries will be white Non hazardous interactions (such as folder generation) will be green Semi hazardous entries will be red Total computer meltdown will be black

14. Phase 1: - Determine the right operating system for the project. This will be run on a Linux server – it is free (completed) - Locate Logs files. And find additional sniffer software that can track changes on the server. (completed) - Find a usable network. (completed) - Test the sniffer software. (completed) digital demise _the planning

15. Phase 2: - Get Flash to read the servers log files across a network (intended completion by 18 October). - Get Flash to translate and organize the log files. (completed) - Design the site (in completion) - Test (see how long it takes for intrusion to occur) – Monday 22 October digital demise _the planning

16. Phase 3: - Launch the site (22 October) - post messages and invitations on forums and bulletins (22/23 October) digital demise _the planning

17. Phase 4: (or Plan B) Install a virus on the server. (lots of hackers use a form of virus to let them know that a server is attackable). A lot of these virus's are on a hacked server that I have access to. They could be used as bait. (24/25 October) Install screen grab software that periodically takes images of the live site over time, to document the activity. (1 November) digital demise _the planning

18. digital demise _the testing phase The server: the operating system must be installed and set up (Monday 15). This will be served on a Macintosh, which will run Linux). Ensure that the security privileges can be relaxed enough so that it is easily hackable – david pope and brad bennie will help in the setup phase. I will attempt to hack it. (Tuesday 16, Wednesday 17). The web page: test that the web page can in fact read or access the log files across the net. The website will be temporarily delivered over an intranet, this will also help tweak securities and privileges (Thursday 18). The hackers: dry run the project online to see how many bites the server takes (Monday 22) The users: allow a selected group of users to test the interface, and gauge the strength of conceptual communication (Monday 15)

19. digital demise _the project so far

20. It has been suggested that the website adopt a tabbed interface so that users may select and view previous stages or versions of the system meltdown. I may have limited access to the kind of bandwidth required for a project of this nature, and so may only be able to track one ‘death’. There are numerous log files created by servers, each one tracks a different kind of activity. It may well be worth tabbing these so that users may view more than one kind of activity at a time, thus enabling users to browse the website as opposed to merely watching it. Obituaries sometimes include images of the deceased, and so it may be necessary to replace these images with the photographic content supplied by the hackers where they become associated with the relevant log entries. digital demise _where to from here?

21. Problem #1: The hackers won't come. Or at least, not on a continual basis. Not enough to note the changes in real time anyway. Proposed solution: 1. I post invitations on forums, and wait for them to take the bait. 2. I record the server changes and loop them back until new changes occur, and feed the new changes into the change loop. 3. I infest my machine with bait virus's 4. As the intention of this project is to document changes by true hacktivism, I suggest that the project run for longer than the intended project deadline, sothat the documentation may be meaningful instead of forced (provided I get to use an uncapped line for an unlimited period of time). digital demise _possible shortcomings

22. Problem #2: The hackers do come. And render my server totally unusable in 19 seconds. Proposed solution: Whilst I think this (or the documentation of this) might be an interesting piece of web art in it own right, I propose that restore points be initiated after the hardware shuts down. This will provide a clean slate. digital demise _possible shortcomings

23. Problem #3: David Pope (one of the collaborators) experienced hacking on a grand scale. 2 000 gigs worth of traffic went through his server, and he was held financially liable for the cost of this. Proposed solution: I may have limited (but sole) access to an uncapped line. Alternatively, I could purchase a prepaid amount of cap limit. However, the project documentation will end when this runs out. digital demise _possible shortcomings

24. Problem #4: Local bandwidth is not good enough for the enormous file sizes shifted by hackers. Proposed solution: If I am able to secure sole use of the uncapped line, this should not pose problems. Analyzing the content of the currently hacked server might indicate that enough hacking will occur to produce enough log file to change the graphic content on the secondary site. Alternatively, I could run a destructive virus, and although we would lose the live hacking, viewers will still be able to watch the digital demise. digital demise _possible shortcomings