Provocations within The Critical Engineering Manifesto (2011) state that reliance on specific technologies are “both a challenge and a threat” and that “the exploit is the most desirable form of exposure”. Julian Oliver is one of the authors of this manifesto and on reviewing his body of work, one can see that the mandate is clearly at the heart of his practice. The Transparency Grenade, Oliver’s most recent endeavour, reimagines the iconic Soviet F1 hand grenade as the chassis for a personal data-leaking device. A concerned individual with physical access to site shrouded in secrecy could simply wait for an opportune moment, pull the pin and create a ‘detonation’ of related data that would be instantly published to the web. The statement for the project describes the operation of the prototype:
“Equipped with a tiny computer, microphone and powerful wireless antenna, The Transparency Grenade captures network traffic and audio at the site and securely and anonymously streams it to a dedicated server where it is mined for information. Email fragments, HTML pages, images and voice extracted from this data are then presented on an online, public map, shown at the location of the detonation.”
With this work Oliver thematically aligns himself with other practitioners of the ‘dark arts’ – artists whose work parses economies of secrecy. However, this project contrasts the transcription and redaction of Jill Magid and Trevor Paglen’s celestial mapping and ‘limit telephotography’ through the production of a performative object; The Transparency Grenade does not present captured ‘secrets’ on a plinth or wall to be read as texts, instead it delivers a precision-engineered workflow for collecting them. More design fact than fiction, the operational logic of the device is currently being rethought as the basis for an application for Android devices (Oliver: “Naturally this is a little more practical than walking into a meeting with a grenade in your jacket pocket”).
The Transparency Grenade just showed at Labor Berlin and last week Régine Debatty posted a compelling conversation about the project with its creator. On being asked to comment on the symbolism of his design, Oliver offered the following explanation:
“I gave The Transparency Grenade this design to signify some of the conversation around cyber warfare, ‘information weapons’ and the Cyber Soldier divisions marching out from national defense budgets worldwide. It can be considered a functional weapon in a symbolically representative container… The volatility of information in networked, digital contexts itself frames a precedent for clamouring (and often unrealistic) attempts to contain it. One could even say it’s this desperate fear of the leak that produces images like my grenade, images that will continue to take violent forms in popular culture, journalism and Presidential speeches in time. In fact the metaphor of a transparency grenade is itself not new, first used publicly by Mike Taylor in the Observer, a few months after I drew up this project. A timely coincidence!”
With these notions of immaterial explosions and ‘live leaks’ in mind, CAN caught up with Oliver to learn more about the design of this device.
Was Wikileaks an inspiration for The Transparency Grenade?
No, it wasn’t. I’ve been interested in the volatility of digital data for quite a while, something that’s turned up in popular culture many times since computer networking crept into the public imagination. I’d like to think there’s a little magic-realism to the grenade I made; building on the myths and fears fed by film and literature as much as the felt anxiety of the leak.
I’m a big fan of Cryptome and have been following their work for about 10 years, much of which is certainly less scandalous than Wikileaks. Nonetheless they’ve proven to be an eye-opening resource over the years, if not only because they cast such a broad and thorough net. They are a tried-and-true, trusted leak service, giving great insight into how some corporations and some government offices falsify facts, conceal or spin data and engineer public opinion.
The pre-assembly photographs and technical drawings of the components of the device make it clear that this was a full-on industrial design project. What were the major technical hurdles in realizing this work?
There were many. This project has been difficult to realise.
First, there’s the issue of fitting so much into so little space – I wanted to keep the volume and shape of the object as close as possible to an actual F1 grenade. In shape it’s almost identical but in size it is slightly larger. In my opinion it feels better in the hand than the replica I own, somehow more throwable (not that mine’s for throwing!).
Secondly was the issue of materials. Initialy I wanted to make the grenade body in cast glass. This would’ve been possible were it not for the fact I really wanted these little cut-away parts on the inside for the inset display and wireless level meter. I next looked into CNC’ing the body from plexiglass but that was both insanely expensive (needing a 4 degrees of freedom mill) and would’ve required a heap of post-processing to give it a quality finish.
In the end I stumbled across this amazing new printable material, Tusk2700T that Materialise, a Belgian outfit work with. That sorted the body out.
Next there was the sterling silver metalwork, done by the talented Susanne Stauch. Not only did it have to provide the locking mechanism of the three-part translucent body but also the trigger mechanism for flicking the lever and providing electrical contact to start the data capture process. We spent many
many hours working all that out and a great solution was arrived at, I think.
The grenade doesn’t have a single screw, hinge or blob of glue. That was a satisfying process and outcome.
Your documentation for the project includes some stills (mock-ups I presume) of a browser-based map interface for archiving detonations. How would you envision this web-service working?
The server side is functional! Under legal advice it’s not sane to let people poke around the data captured during testing (which I’ve deleted now anyway). I could put it up in anonymised form but it would take a lot of work (MAC addresses, remote IPs, Hostnames, email fragments). Best to wait for the Android version, with the server set up at your own risk.
Here’s how it works, first client (grenade) and then server (a Debian GNU/Linux host on the Internet):
There is a relatively primitive configuration interface (CGI), served by lighttpd from the grenade when in Setup (AP) mode. There you can input keys (WEP, WPA) if desired, target particular ESSIDs or BSSIDs, define the remote server, shape the upload bandwith consumed, write to local filesystem or buffer and ‘stream’, audio compression add SSH keys and a few other basics.
Confirming these settings places the grenade in in Armed mode. This toggles a value in a text file that is read by the start up (init) script on reboot telling that script to read the new settings.
Reboot occurs right after the button is clicked.
After rebooting it waits in an idle state until the pin is pulled, triggering the capture.
The software side wasn’t so tricky really as I had a lot of code lying around from previous projects, including projects I’ve been doing with my studio partner Danja Vasiliev. I’m pretty comfortable in a ‘headless’ embedded development space and in reality most work on the grenade client code was wrapping around various utilities with shell scripts, tarballing through an SSH tunnel, some minor work on init scripts and the network stack (wireless tools). I would’ve prefered to use Debian or OpenWRT on the Overo COM I used but stuck with Ångström for if-it-ain’t-broke reasons.
The server-side was a little more tricky, although the map itself was done quickly using CloudMade’s customisation interface for OpenStreetMap. That was fun to work with.
I use iwatch on the server to keep track of file write/close in folders as they are created, named by date and location. As the packet data comes in TCP stream reconstruction starts, sorting by mime-type and writing them out to folders named by stream session. Encrypted data is written for breaking later, should that be desired.
I’m currently using a modified third-party Perl utility for the stream following and HTML markup but may move to tcpflow and foremost for the Android version as it’ll be faster. Audio data is currently Ogg/Vorbis but being a little CPU intensive I may switch to another.
All programming was done in VIM on a Thinkpad running Debian GNU/Linux. Minicom was used for serial communications using a USB Serial FTDI.
More at The Transparency Grenade