a digital scan of a 35mm film image of a processing sketch running on an LCD
Skip to Content

Dead Drop at 319

This morning I installed a dead drop at 319 Scholes street in Brooklyn. Four gigabytes worth of zeroed bits are now available for web-free semi-anonymous file exchange.

Dead drops was initiated by Aram Bartholl during his residency at Eyebeam — the project involves embedding digital storage in buildings or other large, immovable objects in public space. Aram’s “Dead Drops Manifesto” follows:

Dead Drops is an anonymous, offline, peer to peer file-sharing network in public space. Anyone can access a Dead Drop and everyone may install a Dead Drop in their neighborhood/city. A Dead Drop must be public accessible. A Dead Drop inside closed buildings or private places with limited or temporary access is not a Dead Drop. A real Dead Drop mounts as read and writeable mass storage drive without any custom software. Dead Drops don’t need to be synced or connected to each other. Each Dead Drop is singular in its existence. A very beautiful Dead Drop shows only the metal sheath enclosed type-A USB plug and is cemented into walls.You would hardly notice it. Dead Drops don’t need any cables or wireless technology. Your knees on the ground or a dirty jacket on the wall is what it takes share files offline. A Dead Drop is a naked piece of passively powered Universal Serial Bus technology embedded into the city, the only true public space. In an era of growing clouds and fancy new devices without access to local files we need to rethink the freedom and distribution of data. The Dead Drops movement is on its way for change!

Free your data to the public domain in cement! Make your own Dead Drop now! Un-cloud your files today!!!

I really like this project — it sits at the intersection of the practical and the conceptual, and forces us to rethink data exchange and anonymity. In the course of researching dead drops, I read hundreds of comments from visitors to Aram’s blog posts outlining the project. A huge percentage of the comments are henny penny hysterics about the security implications involved in plugging your laptop into a dead drop. (Viruses! Destructive circuitry! Illegal content!) Such is the nature of creative tear-down on the web.

Nevertheless there’s something about drawing data exchange into real life that amplifies paranoia and brings out a sense of peril. If my thesis project about building a decentralized mesh-based alternative internet ends up solidifying, I’ll definitely revisit this issue of how trust works so differently in real life.

Installing the drop was relatively simple. I followed the how-to guide. As fate would have it, there was already a hole in the building’s brick facade that was just the right size for a USB key. With that already sorted, I started by cracking open the key’s plastic case and mummifying it in PTFE tape for water protection:

Next I mixed up some cement, and embedded the key in the wall:

I seeded the drive with a few files of interest, and posted it to the dead drops database — this is the 66th drop to be installed worldwide. I’ll be checking the drive every few days, and if anything interesting shows up I’ll write a post.

I’ll be interested to see how well / long it holds up to the elements, since the Eyebeam drop met an early demise after a rainstorm, and the Union Square drop was lost to vandalism.

November 29 2010 at 9 AM

Building a Real-Time Web Library for Processing

In the course of working on my big screens project this semester — a real-time web clock — I’ve realized that it would be awfully nice to have a Processing library to abstract away all of the footwork involved in skimming the latest data from the usual Web 2.0 suspects like Twitter, Flickr, Facebook, Foursquare, etc.

There’s already some nice work on this front. Mark McBride’s excellent Tweet Stream library for Processing works exactly as advertised. There are also Java wrappers for popular APIs (flickrj comes to mind) that should work in Processing and are likely to make data extraction easier.

But, many of these approaches are lacking, and getting from a raw API to a real-time stream can be a lot of work. So I’ve started work on a Processing library whose sole function is to provide a real-time stream of web data from as many sources as possible, with as little delay as possible.

A few considerations and concerns for the design and implementation of the library are outlined below.

One Library vs. Many
Traditionally, APIs wrappers / libraries come à la carte. You want Flickr? Download the Flickr library. You want Twitter? Download the Twitter library. Etc.

That’s nice, but all of these libraries work in slightly different ways and putting two or more services together requires plenty of fuss and glue code. I think a lot of the interesting things you can do with real-time data involve placing it in the context of other events, which favors a one-library approach.

Also, consolidating the services into a single library means that we can use polymorphism to make dealing with generic “event” objects from different sources relatively painless. E.g., if you wanted to work with tweets and Flickr updates in similar contexts, you should be able to manage everything from a single array list since their event objects inherit from some kind of generic event class.

Not all services with high-rates of incoming data have clean, public-facing APIs for grabbing said data.

In the case of Foursquare, for example, there’s no way to access the most recent public check-ins through their official API. The API allows certain kinds of interactions with the service, but it doesn’t do exactly what we want.

Likewise, Facebook’s status API doesn’t let you do an empty search for all of the latest updates — instead you’re limited to a specific search term. So, in this case, there’s an API that almost does what we want, but we’ll have to get clever if we want something resembling the whole stream of public status updates.

Therefore getting real-time data from these services will involve some hairy HTTP polling and HTML scraping. These kinds of things are liable to break if / when the structure of the source page changes. There are also potential request rate limits to deal with. Keeping the library up to date and fixing breakage when it happens is going to be a challenge — but I can’t think of a way around this until more sites support officially-sanctioned access to structured real-time data through an API. (And good on Flickr and Twitter for providing real-time data in their APIs already.)

Actual Rate vs. Available Rate
Ideally, every single event from a service would be captured by the real-time web library. However, for extremely high-volume services (Twitter, for example), even the official APIs only give a fraction of the actual event streams. Again, there’s not really a way around this, but keeping tabs on what percentage of the full stream we’re currently reading might be useful — some way to compare the current message rate through the library to the actual message rate on the service’s end. (For example, it would be useful to know that the library’s current Twitter message rate is 30% of actual traffic.)

Conversely, being able to dynamically specify a rate limit for each service might be useful in certain contexts where bandwidth needs to be conserved or services need to be synchronized. (At the very least, rate limiting will be useful for my big screens project, where a full-rate sample of the services would result in graphic slowdowns.)

So how should it work from the library programmer’s perspective? Maybe something like this:

  1. WebStream webStream;
  3. void setup() {
  4.   // instantiate the web stream object
  5.   webStream = new WebStream(this);
  7.   // add as many (or as few) real-time services as you like
  8.   webStream.activateFlickr("api key here");
  9.   webStream.activateFacebook();
  10.   webStream.activateTwitter("api key here");
  11. }
  13. void draw() {
  14.   // Nothing to see here, yet
  15. }
  17. void streamEvent(Update u) {
  18.   // the web stream returns updates via a callback event
  19.   // this would print a quick summary of the most recent event
  20.   println("content: " + u.getText() +
  21.           " via: " + u.getAuthor() +
  22.           " at: " + u.getTime() +
  23.           " from: " + u.getServiceName());
  24. }

That’s the plan, at least. I’ll work on this over the next week and eventually have some code for public consumption in the next month or two. If anyone has feature requests or a different take on how something like this should work, let me know.

November 18 2010 at 3 AM

Concept Dump

An ever-expanding list of assorted things of direct or tangential relevance to my continued inquiry regarding a thesis on the subject of a post-apocalyptic pirate internet.

Inventing the Internet - Janet Abbate
Internet Architecture and Innovation - Barbara van Schewick
The Internet Imaginaire - Patrice Flichy
Access Controlled, The Shaping of Power, Rights, and Rule in Cyberspace
Wirelessness Radical Empiricism in Network Cultures - Adrian Mackenzie
Crypto Anarchy, Cyberstates, and Pirate Utopias - Edited by Peter Ludlow
Security in Wireless Mesh Networks - Editors Zhang, Zheng, and Hu

The Temporary Autonomous Zone
BitTorrent Monitoring As a Work of Art
Hacker Spoofs Cell Phone Tower to Intercept Calls
As We May Think

Men in Grey F.A.T.
The Church of Wifi
Archive Team

Assorted wardriving tools

Aram Bartholl
Thomson & Craighead
Gordan Savicic
Danja Vasiliev

Dead Drops - Aram Bartholl
Six Square Meters of RAM - James Irwin


November 16 2010 at 10 AM

Dead Dead Drops

Dead Drops is a project fresh out of Eyebeam that proposes a new and unsanitary means of network-free data exchange. The project seems highly relevant to my nascent thesis idea, The Post-Apocalyptic Pirate Web Kit.

Artist Aram Bartholl describes the project:

‘Dead Drops’ is an anonymous, offline, peer to peer file-sharing network in public space. USB flash drives are embedded into walls, buildings and curbs accessable to anybody in public space. Everyone is invited to drop or find files on a dead drop. Plug your laptop to a wall, house or pole to share your favorite files and data.

It’s the digital equivalent of a glory hole.

I was curious to see what kind of content the drops have accumulated in their first few days of existence, so I printed a handful of maps and set out to visit each one. The site’s location database is a little clunky, but it turned up five drop locations in Brooklyn and Manhattan:

Eyebeam was the first stop. Here’s the drop:

Plugging in was a bit of an anticlimax — nothing happened:

The drive refused to show up on my desktop, and poking around with Disk Utility suggested that the issue went beyond a botched format or a corrupt partition. I emailed Aram about it, and he confirms that it’s gone down and attributes the loss to rain.

The Union Square subway drop also went down earlier today, possibly the result of vandalism. So it goes.

That leaves three more drops to explore, I’ll update this post as I make the rounds.

Even though my attempt to use the drop was a failure (thus far, at least), the concept stands on its own and presents an interesting counter-scenario to the ethereal mesh-networks I’m proposing for the post-apocalyptic pirate internet.

Let’s consider some dead drop novelties:

  • There is no electrical network — feet and subway trains do the work of shuffling packets around the city.

  • There are no loops — a drop is a dead end.

  • There is no censorship — there is no CAPTCHA or filter or firewall. Maintaining a standard of content is perpetually up to the next person to visit the drop.

  • There is no permission — anyone can delete or create any file on the drop indiscriminately.

  • There is no privacy — though the files on a drop may be of anonymous origin, you must be physically present at the drop’s point of installation to exchange data.

  • There is no protocol — where most networks impose a structure for communication (TCP / IP, UDP, OSC, MIDI, AT), the drop’s only structure is derived from the file system.

November 16 2010 at 6 AM

Big Screens is Coming

It’s coming up… December 3rd at the IAC building. Project descriptions and additional info here.

November 15 2010 at 9 PM

MacBook Pro Tick Fix

Disclaimer: This was not a particularly good use of my time.

With that out of the way, here’s a simple fix for anyone experiencing weird ticking noises from their late-model unibody MacBook Pros. Note that this is all a bit obsessive and off-kilter… but since no one else seems to have documented this fix I’ll make an exception and pollute the blog.

My otherwise-trusty 15” model has been giving off an obnoxious, metallic grating sound whenever the chassis flexes or whenever there’s a bit of pressure on the bottom of the case. (For example, when using the machine on your lap instead of on a flat / hard surface.) The sound’s very strange — kind of a combination of bed springs and crickets. It’s a purely mechanical sound, and occurs even when the machine is off. Here’s what it sounds like — you may need to turn your speakers up, as it’s a bit faint:

On the MacBook Pro, the entire chassis acts as an electrical ground. The bottom case cover also needs to be grounded, and Apple’s design maintains contact between the upper and lower portions of a case with a number of spring-loaded contact points. As the chassis flexes during handling, these contact points move slightly against the bottom cover to create the grinding noise documented above. Thus getting rid of the noise is a matter of reducing friction between the contact points and the bottom cover.

This problem has been extensively documented and discussed elsewhere. (The most thorough discussion I could find is this thread on the Apple support forums.)

Some people have gone so far as to remove the grounding spring sub-assembly entirely. This is probably fine, but it seems foolhardy to start ripping grounding points out of your rather expensive and static-sensitive laptop.

Some others have reportedly used small pieces of tape between the spring contacts and the bottom case… this also seems naïve since the tape will act as an insulator and compromise the grounding point.

My solution is to apply a small dab of conductive grease to each contact point. This completely eliminates the grinding sounds without compromising electrical contact between the upper chassis and bottom cover.

Here’s the step-by-step:

1. Gather Materials
You will need your laptop, some isopropyl alcohol, Q-Tips, a #00 phillips screwdriver, and conductive grease.

Note that you want electrically conductive silicone-based grease. Thermally conductive grease, like you would use between a CPU core and a heat sink, is generally designed to not be electrically conductive, and would be no better than using a layer of tape. I used a silver-impregnated silicone-based conductive grease from Chemtronics, part number CW7100. It’s tough to find and obscenely expensive. The best price I could find for a tube was $21 from All-Spec Industries. (And here’s a PDF of the datasheet, for those inclined.)

2. Remove the bottom cover
Remove the 10 screws securing the bottom cover to the chassis. Gently pry off the bottom cover.

3. Identify and clean the contact points
With the cover removed, you will see the offending pair of spring-loaded grounding contacts near the RAM in the center of the machine. (Enlarged at left.) On the bottom cover, you will see several other points of contact — about a dozen in all — identifiable by their slightly rough texture relative to the rest of the aluminum. (Right, circled in red.) Dip a Q-Tip in isopropyl alcohol and clean off each of these bottom-cover contact pads to make sure they’re free of oil and dirt before moving on to the next step.

4. Apply conductive grease
Add a tiny dab of grease to each of the 12 contact points. Try to keep it clean, and limit application to the confirmed points of contact. A detail of the center two contact points before grease application is at left, and the after is at right.

5. Remove conductive grease
You only need a thin layer of conductive grease to do the job, and you absolutely do not want any excess grease getting onto the logic board where it could create computer-killing short circuits. So after the initial dab of grease, take a couple clean Q-Tips and wipe off almost all of the grease you put down. The contact points should look something like this when you’re finished:

6. Reassemble
Replace the bottom cover, secure it with the 10 screws.

And that’s it… my machine has’t made a noise since.

Before you have a field day with your machine, make sure you’re actually dealing with this particular issue. There are a few other potential causes for similar sounds… a dying hard-disk sometimes makes clicking sounds, and even a healthy hard disk will make a small clicking sound if you move the machine suddenly and it decides to park the heads. If your machine makes the clicking sound even when it’s powered down and specifically when you apply pressure to the bottom cover, then you’re probably dealing with the issue described in this post.

I’ve only tested this in my 15” model. I know the same issue has been documented on the 17”, not sure about the 13”. If you have the ticking problem / success fixing your non-15” model let me know in the comments and I will update the article accordingly.

A quick disclaimer: This fix might void your warranty, although if you’re sparing with the grease I’m not sure an Apple-tech would notice. Use common anti-static sense: Be sure to ground yourself before opening up your computer. Don’t touch anything inside that you don’t absolutely have to.

November 5 2010 at 9 PM

Thesis Map

Thesis concept map

A few works / concepts / aesthetics related to the post-apocalyptic pirate internet.

Class discussion brought up the following:

  • The “no disasters” and “auto-disasters” drop-down options in Sim City 2000
  • Tension and contradiction between Dead Drops and The Temporary Autonomous Zone
  • “8 bit with curves”, zine aesthetic
  • Dead Drops’ illusion of deeper connection, despite being an isolated blind pouch
  • Banality of Evil
  • Firesheep
  • Screen recording
  • What can be untethered? Find analogous (and analog?) structures.
November 2 2010 at 1 PM

Metal Box

finished metal box

This week’s box is made out of… metal.

Work started with a nice big sheet of 20 gage cold-rolled A366 steel. This stuff also goes goes by the name “Alloy 1008” — which is 99% iron, with traces of carbon, manganese, phosphorus, copper, and sulfur. (Big thanks to Hana Newman for organizing a group-buy for the class.)

I decided to make a slightly smaller box than Peter demonstrated in class — opting for a 4” square footprint, with 1.5” tall sides. I added 1/8” in each dimension to account for the width of the bends. I started by cutting a 7 1/8” square sheet on the large metal sheer. The cuts wind up much cleaner if you bias the handle of the shear inward on the down stroke.

and then folded up the sides on the hand brake. Like all things in the ITP shop, the brake was slightly out of whack. I should have loosened and adjusted the removable blocks to put them into better alignment before making the bends.

Next I snipped and folded over the end tabs. My bends were slightly off, though, so the box ended up with one tab on the inside, and the other tab on the outside. Next time I’ll make sure the tabs are folded more precisely with respect to the first two bends.

Finally, rivets were used to hold the box together. Drilling holes for the rivets was tricky (particularly when the tabs were “inside” the box). I built a small jig with some wood to drill into a and a metal pin (a screw, in this case) that I could brace the box against and use to push the tabs into alignment during the drilling process. The whole thing clamps to the corner of the table so the box could “sit” on an inside wall without interference from the other side of the box.

The jig is at left, a close up of the cut from the metal shear is at right.

Drilling jifShear cuts

October 27 2010 at 12 PM

Project Status

The VHS Can(n)on is coming together, albeit a bit slowly. At this point I’m still in the process of gathering parts. So far I’ve secured a consumer-grade Sony VHS player with a jog dial and nice big play / pause buttons. I’ve also picked up a WiiMote (for pointer tracking) and a handful of VHS tapes courtesy of Sofy (Standards like Clueless, the original Star Wars trilogy, and a Daft Punk video).

I still need a means of getting the composite video feed from the VHS player into my computer (and from there into Processing or OpenFrameworks). I’m sifting through a bunch of different options from B&H.

Once that box is in hand, I’ll have enough to implement the most basic elements of the system. It’s important to do this soon since I’m not yet sure how much I’ll have to hack up the VHS player’s interface to build a usable set of interactions.

October 26 2010 at 6 PM