Graffiti Networks Project ate my wiki!

Today I noticed something strange while backing up the database from another website I manage, ComWiki. The database backup took much longer than usual, and I was surprised when the size of the backup started to go over a gigabyte. Either someone had been adding lots of pages to the wiki, or something weird was going on.

So I went to the “All pages” page on the wiki and noticed a bunch of pages with strange titles that appeared to be spam-like URLs. Visiting those pages gave me a big shock, as the content appeared to be some kind of binary code. It sort of reminded me of the old Usenet rar files, line after line of gobbledegook that looked suspiciously like a slice of Warez.

Then I got an even bigger surprise, when I got a message on my screen that Google had detected malware on the site. Oh boy.

After doing some more digging, I found a note from something called the Graffiti Networks Project. Apparently, this was a project started by a couple of students at Brown University to exploit a weakness in MediaWiki, the open source software that runs Wikipedia (and the software I use on ComWiki). Essentially, the project demonstrated how one could use this weakness to establish a peer to peer file sharing network.

Here’s the more technical description from their website:

In response to the lack of user anonymity and long-term data persistence in existing P2P systems, we developed the Graffiti Network distributed file sharing protocol that uses multiple third-party storage sites as a data replication and transfer medium between clients. Our approach is to use publically available web sites to store multiple copies of shared content. We use the term graffiti for our work since we are storing data in a way that non-network participants may regard as unsightly or unwanted vandalism.

Employing the same concept of a central tracker as in the BitTorrent protocol, a Graffiti client will connect to a tracker and receive well-defined instructions on where and how to retrieve segments of shared files from a remote storage site. Upon successfully downloading and decrypting some portion of the shared data, the client will receive further instructions to replicate that same data at different storage site. If the client succeeds in replicating the data, it notifies the tracker of the new replica location to receive the next data segment it needs and then repeats the process. Our approach has several key benefits over other P2P systems where clients transmit data directly with each other:

A newly arriving peer can still download files even if all other peers have long disconnected
A peer does not need to know about the existence of other peers
A tracker does not need multiple peers in order to enforce tit-for-tat policies.

Wow. You would think they would have at least asked me first before they started hacking at ComWiki. But then I guess that would spoil the fun.

Anyway, I’ve taken ComWiki down for now and put up a “parking page” until I can sort out this mess. When I do get ComWiki back up, I’ll probably have to put up a bunch of security measures, like CAPTCHA-style “type the letters you see in the box” routines, in order to keep out spammers…and Brown University students.

I can understand the theory behind this “experiment.” But I don’t appreciate the ethics, or lack of them, in its execution. I get the impression that these students felt that they were simply testing a “proof of concept,” and that no harm was done by storing their “encrypted data payloads” on wiki pages. But just because something CAN be done doesn’t mean it SHOULD be done. In the social sciences, I doubt if this kind of “experiment” would ever be approved by a human subjects research board.

Sure, running an open wiki means one has to expect some vandalism. I’ve come to expect some “edit wars” when running an open wiki, as people try to use the wiki to advance a particular agenda. Yet I’m still a real believer in the value of open wikis. I like the fact that on an open wiki, one can quickly correct a typo or add an important point to an article. No need to register, no need to squint at a CAPTCHA. Just hit edit and do it. Free and open. Anyone can edit. Yes, that means you have to expect edit wars, but that’s part of the wiki culture. And sometimes you can learn a lot from edit wars. If nothing else, you learn something about those who feel so compelled about their views that they take the time to engage in an edit war.

But to set up a P2P system that exploits this openness takes the “edit wars nuisance” to whole new level, one that just seems wrong to me. I don’t really care if people want to use the internet to share music or movies or warez. Indeed, that’s become part of the culture of the internet, and there’s not much I can do about it. Nor does it seem there is much the RIAA and MPAA can do about it. But to exploit a weakness in MediaWiki (and in particular, a default open installation of MediaWiki) just seems to spit in the face of the Wikimedia Foundation, one of the biggest defenders of openness on the internet.

In my opinion, the real shame in all of this is that when I finally do get comwiki.org back up, it will have to be a more closed wiki, which defeats one of the major advantages of a wiki: the fact that “anyone can edit it.” In fact, at one point I did have comwiki.org more closed, so that only registered users could edit articles. But when I did so, I noticed a significant decrease in edits from users. So I opened it back up, thinking that this might encourage a more open, freely-editable wiki experience. It was just such a freely open wiki environment that these students sought to exploit with their P2P experiment. And now it looks like I’ll have to lock it back up. What a pity.

By the way, even though the Graffiti Networks Projects’s web site claims they used their “removal tool” to delete their “encrypted data payloads” as of April 11, three weeks later I am still getting tons of hits to the wiki from bots. In the time it took me to manually delete a bogus wiki page and its edits, another page or two would pop up. So far this month, the traffic on this site is over 12 gigs. And even after completely removing MediaWiki and putting up a temporary parking page, the domain name is still getting hundreds of hits every day.

Just added a twitter widget

Since I’ve been twittering a bit more lately, I decided to finally add a twitter widget to my blog. You’ll see it at the top of the right column, at least for now. It does require Flash 9, so I may need to tweak it a bit if it doesn’t degrade gracefully to HTML. It’s also a bit wider than some of the other widget I have running on my blog, so again, I may need to tweak it. But for now, it’s a quick way to integrate my “tweets” into my blog.
twitter_logo_header
[Edit: I fixed the width issue pretty quickly. Just a matter of changing the width attribute a couple of places in the code. Now the widget looks like it belongs there.]

iPhone 3G

So I finally had to buy an iPhone 3G.  I had talked about why I didn’t buy a first generation iPhone in an earlier post, and I’m glad I waited.  The iPhone 3G was truly worth the wait. 

I had wanted to get one of these phones back in July.  After standing in line for two hours at a local Apple store, I gave up.  But a little over a week ago, I was lucky enough to find a black 16 GB model in stock at an AT&T store.  No line to wait in, and although it took awhile to activate, it was a relatively painless process.  Plus by purchasing at an AT&T store, I was able to get my employer’s discount on cell phone service.

I’ve got to say that this is the first cell phone I’ve owned where I can actually use email and web applications.  While I’ve tried various “mobile web” enabled cell phones in the past, none of them provided a very usable experience.  Even if I limited myself to websites optimized for mobile devices, trying to surf the web on a phone was like trying to watch a movie through a straw.

Of course, the iPhone 3G isn’t perfect.  I wish it could handle flash.  I wish AT&T’s network was a bit more robust, especially the 3G coverage.  And I wish the new pricing plans included unlimited texting (something that was included in the original iPhone plans).

But I’m willing to put up with these minor annoyances for a phone that can let me read my email, surf the web, store my contacts, snap a quick photo and keep my calendar handy.  And yes, make an occasional phone call, too.  I think I’ve fallen in love.

More on blogging with touch

Another day, another try with blogging on the iPod Touch. One nice feature of the wordpress iPhone blogging tool is the ability to store local drafts of posts. So while it takes longer to type an entry, one can take a break, save the local draft, and return to writing later.

The onscreen keyboard takes some getting used to, but I’m starting to get the hang of it. Still, I’m not as well versed in the “texting” approach to typing. My thumbs seem to big to type accurately while using both of them. Perhaps I’d be better at this if I had pointier thumbs. I seem to do better using one finger.

Now broadcasting on Mogulus.com

I’m trying out the beta of Mogulus Studio on mogulus.com.  It’s a pretty slick web 2.0 application for creating personal video channels.  I posted some short videos from a train trip I took this past weekend. Check out the channel I created on http://www.mogulus.com/drthompsen.  They even let you post a “widget” of your channel on your blog…




I’ll have to kick the tires around a bit more, but so far, Mogulus Studio looks like a great app.  And it’s free (if you agree to have their ad banners on your channel). There is one caveat: since it’s flash based, don’t expect to use it on your iPhone.  At least not yet.

A GameBoy for learning?

The GameBoy has been a big hit for youngsters (and oldsters, too), so I’m not surprised that Innovations For Learning’s new Teachermate handheld computer looks a lot like a Nintendo GameBoy. The size, button layout, and color scheme all give the impression that this is a fun gadget that Mario or Sonic would be pleased to call home. But upon closer inspection, the Teachermate looks like it could be an intriguing educational tool.Teachermate

At the moment, the device is designed for elementary reading and math applications, but the SD card slot suggests that it could be used for much more than that down the road. If Innovations for Learning releases an SDK for it, I for one would be very tempted to get one just to try it out. They only cost $50, which is considerably cheaper than a GameBoy (although as I write this, they are listed as “out of stock” at Amazon).

In addition to the SD slot, the Teachermate has a 200 MHz ARM processor, half a gig of RAM, built-in speaker, headphone jack, and built-in microphone. Its battery can be charged up via an AC adapter, a USB connection to a computer, or using the optional “Synch and Store” device that can recharge and synchronize a classroom’s worth of Teachermates.

While I got the impression that this is a product still under development, it does look promising. Of particular interest to me were two research studies (funded by grants from the Spencer Foundation) showing positive results in early trials of the device. This is certainly a technology to keep an eye on. Read more about it at http://innovationsforlearning.org/.