I don't see why what you describe is such a risk. This risk exists already with FTP files and anything you download from the Web. Why should Napster be so special and different in this respect?
The reason it works like that is because the backend was changed recently from a substring-match-class searching mechanism to a keyword/token-based matching mechanism. Most people don't experience the difference, but to the few who do: such is our price for making a better search engine.
> and has some pretty bad security holes that > means that potentially the client can be forced > to serve up any file to a malicious Napster > server.
So far noone has offered up any real evidence that this is actually the case. Just a bunch of FUD.
Here's how the client works:
1. build a file list. add only files that constitute valid content (currently.mp*. look for mpeg headers). 2. when a request comes in to the client, match that request against the file list. 3. if it is in the file list, accept the request. if not, then don't.
It's just that simple. There is no complicated key exchange, no extensive encryption calculation, no tedious obfuscation algorithm. Just your basic plain old strcasecmp() on a list.
Can you trick a client into sharing content it shouldn't? Sure, you can trick your/own/ client into sharing, say, sam._, provided you stego the thing with a valid mpeg header and give it a.mp* extension. But it's/your/ data, you're not tricking anyone, you're making yourself vulnerable.
So far everyone thinks there is a security risk in Napster, but noone has offered up proof. I purport that there isn't anything to attack; the algorithm is so simple and effective that there isn't much place for loopholes.
Try a competitor program, like Imesh, and search for "sam._". You will be surprised at the results.
If exponentiality is fatality, as one writer suggests, then information is creating a new kind of ecosystem that violates natural laws of selection and survival.
The premise here is fairly absurd. You're comparing the properties and characteristics of things that are material and tangible with things that are not. Over-population, over-proliferation of biological life does not map directly (or even similarly) to the over-proliferation of information. The characteristics that make over-population bad, such as exhaustion of resources, spatial constraints, etc, just do not apply to electrical impulses on a wire!
Indeed, the premise is antithetical to Metcalfe's Law: The usefulness of a network equals the square of the number of its connections.
In other words, exponentiality, where information is concerned, is the key to ultimate utility.
Some people's ignorance just astounds me. I've heard at least 5 people conjecture about the language it was written in, how fast it is, etc. Noone has yet to make a bit of sense. Or figure it right, for that matter.
Delphi is a great RAD tool and for production code is arguably no better suited than VC++ (what the client is written in), and BP (if you weren't kidding) wouldn't bring you any closer, and might even be less function capable given the multithreading and complex mutexes involved. Some idiot even swore up and down that it was written in VB (ugh!).
For the record: client is in VC++, server is in GNU c++.
This is an attempt by Micro$oft to get free QA. Unless you like doing work for monolithic, monopolistic companies and not getting paid for it, don't even look at the box.
You do more for yourself and for the community that Micro$oft oppresses by waiting until Windows 2000 goes Gold, publishing your sploit on BugTraq or some other full-disclosure security forum, and seeing it on the front page of the New York Times.
Cracking their box is helping them for free. See through the folly; they don't deserve anything.
hardly. past setihome clients I've seen have caused noticable performance degredation on the server over all. at least moreso than other distributed computing clients. IMHO.
Slashdot Mirror
I don't see why what you describe is such a risk. This risk exists already with FTP files and anything you download from the Web. Why should Napster be so special and different in this respect?
What about WMA? Or other audio formats?
--jordan
The reason it works like that is because the backend was changed recently from a substring-match-class searching mechanism to a keyword/token-based matching mechanism. Most people don't experience the difference, but to the few who do: such is our price for making a better search engine.
--jordan
> and has some pretty bad security holes that
.mp*. look for mpeg headers).
/own/ client into sharing, say, sam._, provided you stego the thing with a valid mpeg header and give it a .mp* extension. But it's /your/ data, you're not tricking anyone, you're making yourself vulnerable.
> means that potentially the client can be forced
> to serve up any file to a malicious Napster
> server.
So far noone has offered up any real evidence that this is actually the case. Just a bunch of FUD.
Here's how the client works:
1. build a file list. add only files that constitute valid content (currently
2. when a request comes in to the client, match that request against the file list.
3. if it is in the file list, accept the request. if not, then don't.
It's just that simple. There is no complicated key exchange, no extensive encryption calculation, no tedious obfuscation algorithm. Just your basic plain old strcasecmp() on a list.
Can you trick a client into sharing content it shouldn't? Sure, you can trick your
So far everyone thinks there is a security risk in Napster, but noone has offered up proof. I purport that there isn't anything to attack; the algorithm is so simple and effective that there isn't much place for loopholes.
Try a competitor program, like Imesh, and search for "sam._". You will be surprised at the results.
--jordan
The premise here is fairly absurd. You're comparing the properties and characteristics of things that are material and tangible with things that are not. Over-population, over-proliferation of biological life does not map directly (or even similarly) to the over-proliferation of information. The characteristics that make over-population bad, such as exhaustion of resources, spatial constraints, etc, just do not apply to electrical impulses on a wire!
Indeed, the premise is antithetical to Metcalfe's Law: The usefulness of a network equals the square of the number of its connections. In other words, exponentiality, where information is concerned, is the key to ultimate utility.
--jordan
Some people's ignorance just astounds me. I've heard at least 5 people conjecture about the language it was written in, how fast it is, etc. Noone has yet to make a bit of sense. Or figure it right, for that matter.
Delphi is a great RAD tool and for production code is arguably no better suited than VC++ (what the client is written in), and BP (if you weren't kidding) wouldn't bring you any closer, and might even be less function capable given the multithreading and complex mutexes involved. Some idiot even swore up and down that it was written in VB (ugh!).
For the record: client is in VC++, server is in GNU c++.
FYI.
--jordan
This is an attempt by Micro$oft to get free QA. Unless you like doing work for monolithic, monopolistic companies and not getting paid for it, don't even look at the box.
You do more for yourself and for the community that Micro$oft oppresses by waiting until Windows 2000 goes Gold, publishing your sploit on BugTraq or some other full-disclosure security forum, and seeing it on the front page of the New York Times.
Cracking their box is helping them for free. See through the folly; they don't deserve anything.
--jordan
hardly. past setihome clients I've seen have caused noticable performance degredation on the server over all. at least moreso than other distributed computing clients. IMHO.
--jordan