Over the weekend, I finally had the time to sit down and do some serious technical thinking about a quick-hack music-specific client to run under 0.2. My conclusion is that such a client is not worth the effort. The political and technical issues of music-centric clients in general are still open as far as I'm concerned, but a quick-fix 0.2 music client is no longer on my own list of potential projects.
I do think it is possible to get a marginally-usable, functional client out the door in a matter of days. By making some admittedly ugly and insecure compromises in the way of publishing lists of valid file names, a usable system could indeed be created on an emergency-hack basis. Unfortunately, a lot of problems would remain -- some of them severe. For example: I spent much of the weekend just figuring out what Mr. Sandberg, by coincidence, mentioned this morning in the thread "Freehaven crossover": > The best way to crash Freenet as it is today (0.2) is to run a node > that returns bogus data on all requests. Because every false reply > means more references back to the bad node, it would slowly pollute > the whole system. The 0.3 version takes measures that should make > this drastically more difficult (see KSK). Bullseye. An "in your face" music client to serve as a refuge for the Napster-deprived would surely have a hostile node somewhere in the system. I can't think of any practical way for an 0.2 client to keep someone from publishing bogus files with impunity, and 0.2 itself doesn't address the issue as far as I could tell. I'm a Java newbie, so I could well be wrong, but when I read Oskar's comment this morning, it really increased my confidence level. Inserting bogus data under valid file names is one of the first thigns that attackers would try (<http://www.stopnapster.com/trojans.html>). It appears that even one hostile node can do serious damage in 0.2, especially to nearby nodes, and especially if the hostile node is the among the first to start distributing a given song name. There's a lot I can do on the client side to cut down on this sort of thing. Just putting a short hash value in the filename itself would make it more difficult for hostile nodes to generate files that fit the naming criteria -- a sort of poor-man's CHK on the client side. It isn't difficult to think of many different ways to try to address this and other 0.2 problems; but such attempts are likely to take a lot of time to develop, probably have holes in them, and are likely to merely duplicate better work on the same problems that is already underway in 0.3. If I'm wrong here, I'd love to be corrected. If I could get an acceptable level of performance out of 0.2 with only a few quick changes, then it might be worth pursuing. As near as I can tell, though, we'd do better to just sit back and wait for 0.3 or better. The stay on the Napster ruling will help, as well as the plethora of Napster alternatives out there. Simply telling users "sorry, but we're just not ready" appears to be safer than the risk of offering a hurried product that gets compromised by a relatively simple attack. Critics of the idea can justly feel affirmed, but I'm very glad I made the effort to look into this. It was a good incentive for me to sit down and start learning Java, with a real-world problem in mind. Thanks for suggesting it, Ian. Thanks also to those who didn't like the idea, for your helpful feedback. One closing note: To those who are interested in developing music clients, long term or otherwise, please try to keep client discussions on the client list. I continued the thread on this list only because it started here, but it seems clear that continued development of the concept would be primarily a matter for the client list, not the dev list. --willdye (not speaking for my employers, who think I should get more sleep on weekends instead of doing outside coding projects like this) willdye at freedom.net _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
