Napster Attacks Open Source Clone
Anonymous Coward writes "In a
letter, the author of a Gnome-based
Napster clone was pressured
to remove distribution of the program due to the fear that
source availability would make the Napster servers less secure [if]
gnap
is not ceased." UPDATE by RM: Ryan Dahl, gnap author, has spoken with Napster, says they've come to a happy understanding, and has removed the "letter from Napster" (and his response to it) from his page. He also tells us that he and Napster are working together on an article for tomorrow, which we eagerly await.
and end this before it gets silly, non-issue.
+&x
From the gnap homepage:
1999.11.29
Thank you to all the people that supported me today. The situation was fairly heated for awhile. All I really want to do is code this client. Let me say that Napster (the person) and I discussed this issue completely. He was very resonable and nice when I got to talk to him alone. I hope we can work together to make Napster a good service.
gnap is and will continue to be GPL.
---
What makes some of these companies think that whenever somebody writes a piece of software that exploits the flaws in their software, it's not their fault? This is just like the whole DeCSS business. Big (well, Napster isn't that big in this case) corporates trying to protect their "proprietary" software when the only reason it needs protection is because it's weak. It also seems pretty hipocritical to me when Napster, a company which is basically devoted to assiting people engaging in music piracy, tries to shout the same "it's mine!" call as the music industry. I don't know about you, but this I downloaded the gnap source code as soon as I saw this posted.
There's no reason for a sig here.
Miguel de Icaza's activity log has a link to the irc discussion that the author of gnap had with the people from Napster. I am not sure if this discussion took place before or after he received the letter.
Look at the comments on the main page.
The Napster guy is valid in his assumption that open specs will cause lots of hacking. However, he seems to forget that keeping it closed will not stop hacked clients from emerging. Gnap is proof of this.
If you're going to bombard Napster with email, don't flame. Just indicate that security-through-obscurity simply doesn't work. Any sort of protective measures he wants to do should be done on the servers, not so much the clients which everyone has access to.
I personally would like to see lots of encryption.
Roblimo, at least look at the link before you post a story. There's been a number of stories on /. lately that caused a lot of problems for a few people and got a whole lot more people in an uproar simply because the story poster didn't check the linked story properly.
I think that the headline for this story is very very very misleading. This is like the 5th time in the last couple weeks that /. has ramped things up more than they really are. He says specifically that Napster (the person) was a nice guy.. doesn't sound like a threatening attack to me from what I read. Please, try to be an unbiased news source from now on, I'm resorting to ignoring any and all comments from the posters at this point (Especially Roblimo and michael, hemos at least apologized)
I'm not trying to start a flame war,but I hope someone pays attention to this.
Dacels Jewelers can't be trusted.
According to this Salon article lovingly preserved by Yahoo news service, they have indeed started to try and do just that:
Hi!
I have removed the logs and emails on the gnap site because they do not show Napster (the company) in very good light. This disision was mine and mine alone.
I had a long chat with Napster (the person, the owner of the company) this afternoon, and we worked everything out.
Many of the gnome developers had a meeting this afternoon (which I didn't join) with napster about this whole issue, everyone learned alot. After reading these logs I feel alot better too.
It turns out that Napster's (the person) request to have me remove the source code, was a request as a person (which didn't come clear across to me) not as a company. After that I wrote a letter back to them saying I would not remove the source. Then Saterday afternoon Napster (the person) his co-worker (?) nocarrier and I had a chat.
To say it bluntly, they were being rude and I was feeling threatened. (I WAS NEVER THREATENED THOUGH)
For about 24 hours the sourcecode was offline, before I decided to email them saying I would not take it off. That was that.
They have no legal case, nor do they want any legal case.
This has all been cleared up hours ago. I will put this on the gnap page.
-- four
1 - Napster owns the servers that the client uses. Period. They provide the servers for use by the client. Any unauthorized client using the servers is just that - unauthorized. This is exactly the same as someone relaying mail through your server that you do not authorize, and they should be equally free to do whatever they wish to make sure that only authorized clients use their servers.
2 - The service is provided without charge to the user. The client is provided without charge to the user. This does not == free, and it does not == public domain. The 'rights' of the users are just that of any other service - use it, enjoy it, if you don't like it, well... in so many words, shove it. I have yet to see someone build a free public domain server architecture and client to do the same, and when they do I hope that all of you will support it with gusto. Until then, you frankly have nothing to complain about. I don't see what is so wrong with using the client provided to you, and if you want to build your own and your own backend and open source it, more power to you.
As I understand the fear is that hacked napster clients will be able to report incorrectly what mp3's I have availible. But what prevents me from merely creating files of the appropriate size filled with random bytes?
It would appear that it is easier to fool the napster program in such a manner rather than messing with the source. Everyone can make a file not everyone can code a client.
Secondly who are they scared of? Even script kiddies probably have something better to do than falsely posting mp3's. If it is groups such as the RIAA flooding the server to make it unusable....well they could certainly reverse engineer the client just as well as I can.
Thridly while in this case the client seemed to be easily reverse engineerable security through obscurity is not impossible. If you capture a piece of my own private code the fact that you are unsure of the algorithm renders it difficult to decode (Re: those papers supposedly detailing buried gold in virginia where only one has been decrypted). Sure it isn't as secure as a well tested publicly availible algorithm but if your intent is to hide the actions of an algorithm your choices are limited.
Hell if security through obscurity never worked the wine project would be done.
Marriage is the "pseudo-ethics" that cloaks the messy truth of sexuality in the raiment of propriety -- it's "Don't Ask,
I guess this is a little offtopic (if Slashdot had a general posts board I suppose it'd go there) but I've been seeing a lot of posts criticizing the headings/content/comments of topics lately. People criticizing i.e. Roblimo for "Napster Attacks Open Source Clone" (others come to mind, such as the ID spying post and the Bruce Perens vs. Corel thing).
I just have one thing to say. Grow up.
Slashdot as a media source is not your classic 1/2 hour news jive. It's an immediate source that shows what's being said in the moment, links us to where it's being said, and let's us hash it out on our own. So when it gets wind that something happens, when it gets a link to a rather rude (I take it, I didn't get to read it) email that may be threatening, it is Slashdot's place to post it. Things change, and updates can (and in this case, I expect will) be made. If you don't like it a little raw, what are you doing here in the first place?
Jose M. Weeks
What we really need, is a distributed form of the napster service. The protocol could be based loosely around IRC.. in fact it might just be easier to sit it on top of the IRC protocol. In any case, its not a terribly complex protocol.. and it would be so much nicer if the servers were distributed. Granted there is the whole speed issue.. but with some caching thrown in it could be pretty decent. We need a completely decentralized file search service ...
oh... and of course.. it'd be much harder for people to squash the service for distributing ~1 TB of mp3s =]
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)