Skip to main content

Brown project spamming MediaWiki sites

A few weeks ago I noticed some very strange looking pages showing up on the TinyOS Docs Wiki which I maintain. These pages contained what appeared to be ASCII-encoded binary data of some kind, although the format was not anything I recognized. Cursory searches for what might be causing this turned up nothing, so I ended up spending a couple of hours locking down the site to prevent malicious edits.

Turns out this was (what appears to be) a student project from Brown called Graffiti which is intended to provide a kind of encrypted, distributed filesystem (I gather, since the paper isn't available) on top of "public" MediaWiki sites. (I should point out that the bogus pages on my site did not have the explanatory message at the top saying that they were related to this project - I guess this was only added in a later version of their code.)

The authors seem to be reticent about the trouble they have caused, but a comment that previously appeared on the project page suggests that they don't quite get why this is such a problem:
03/09/2009 - Rejection!
Our paper got rejected from IPTPS. One of the main points brought up by the reviewers was that our system was not a true peer-to-peer system. Most reviewers also seemed appalled at the idea of commandeering abandoned websites in order to store illegal content. Nevertheless, we are not deterred and will be searching for the next workshop/conference that is bold enough to take on the ideas of the Graffiti project!
(Seen on this discussion board.)

Now, while the idea of a distributed filesystem riding on top of "open" sites is cool, the way the authors went about this is problematic. Just because some MediaWiki sites are open doesn't make it OK to spam them with bogus pages for the purpose of doing your research -- I am sure this violates both the terms of service of Brown's network as well as the networks of those sites they spammed.

There are better ways to evaulate this system than to hammer on unprotected wiki sites without permission. They could have used PlanetLab and run their own wikis to evaluate the system's scalability and robustness. They could have asked permission from site owners with a promise to clean up after themselves after the experiments were run. I hope the authors are kidding about the "bold enough" comment above. It suggests they underestimated the legal and ethical issues raised by spamming open sites just to get a paper published, nor the amount of hassle they have caused sysadmins of the affected sites. I just hope they learned some kind of lesson from this.


  1. I am surprised that they did not use twitter! That way they could setup accounts whose (140 byte long) updates could be the content they want to distribute. Plus, since those accounts need not follow or be followed by anybody, it is possible that they are not considered spammers (and since the above is content only among users of the platform one needs to know who to read in order to reassemble the desired files).

    Since there exist many twitter-like networks now, one can distribute content both on users and networks.


Post a Comment

Popular posts from this blog

Why I'm leaving Harvard

The word is out that I have decided to resign my tenured faculty job at Harvard to remain at Google. Obviously this will be a big change in my career, and one that I have spent a tremendous amount of time mulling over the last few months.

Rather than let rumors spread about the reasons for my move, I think I should be pretty direct in explaining my thinking here.

I should say first of all that I'm not leaving because of any problems with Harvard. On the contrary, I love Harvard, and will miss it a lot. The computer science faculty are absolutely top-notch, and the students are the best a professor could ever hope to work with. It is a fantastic environment, very supportive, and full of great people. They were crazy enough to give me tenure, and I feel no small pang of guilt for leaving now. I joined Harvard because it offered the opportunity to make a big impact on a great department at an important school, and I have no regrets about my decision to go there eight years ago. But m…

Rewriting a large production system in Go

My team at Google is wrapping up an effort to rewrite a large production system (almost) entirely in Go. I say "almost" because one component of the system -- a library for transcoding between image formats -- works perfectly well in C++, so we decided to leave it as-is. But the rest of the system is 100% Go, not just wrappers to existing modules in C++ or another language. It's been a fun experience and I thought I'd share some lessons learned.

Why rewrite?

The first question we must answer is why we considered a rewrite in the first place. When we started this project, we adopted an existing C++ based system, which had been developed over the course of a couple of years by two of our sister teams at Google. It's a good system and does its job remarkably well. However, it has been used in several different projects with vastly different goals, leading to a nontrivial accretion of cruft. Over time, it became apparent that for us to continue to innovate rapidly wo…

Running a software team at Google

I'm often asked what my job is like at Google since I left academia. I guess going from tenured professor to software engineer sounds like a big step down. Job titles aside, I'm much happier and more productive in my new role than I was in the 8 years at Harvard, though there are actually a lot of similarities between being a professor and running a software team.

I lead a team at Google's Seattle office which is responsible for a range of projects in the mobile web performance area (for more background on my team's work see my earlier blog post on the topic). One of our projects is the recently-announced data compression proxy support in Chrome Mobile. We also work on the PageSpeed suite of technologies, specifically focusing on mobile web optimization, as well as a bunch of other cool stuff that I can't talk about just yet.

My official job title is just "software engineer," which is the most common (and coveted) role at Google. (I say "coveted&quo…