Slashdot Mirror
MUTE: Simple, Private File Sharing
oohp writes "MUTE is a new file sharing network that provides easy search and download functionality while protecting your privacy. It does this by routing all messages through a network of neighbour connections, using virtual addresses and encrypting all the traffic (using RSA for public/private keys and AES for the actual encryption). MUTE's routing mechanism is inspired by ant behaviour. The program is available for Linux, Windows and Mac OS X."
Well, I just installed it at home (thanks, VNC!) and did a search for "mp3" assuming that would generate a lot of hits but haven't seen anything happen. The docs are sparse, to say the least. "Is this thing on?"
Trolling is a art,
All I got was a 404 when I tried to find the Crowds homepage (AT&T research labs), but it was one of the privacy-enhancing technologies I looked at while doing my thesis. It's a similar concept with connecting to many different nodes than directly with who you want to communicate with, download files from, etc.
People say I'm crazy, I got diamonds on the soles of my shoes...
The files do not belong to the RIAA. Few if any of the files on Kazaa belong to the RIAA (and only if the RIAA is actually listing them for download).
Here, CPD isn't looking for plagiarism; instead, it's looking for opportunities for refactoring.
As their Sourceforge page says, it only aspires to pseudo anonymous P2P.
your right. it isn't anonymous per say. but if both you and i were nodes in this system then your TCP/IP logs and ISP logs would show that i downloaded something from you or vice versa.
however i may have been a stopping point for the data in a similiar way that proxy servers are a stopping point for highly requested html pages. so that can't say that "I downloaded it" because i may have simply just been relaying the request
True, I haven't tried it, but I've read the spec. You should do the same before commenting further.
The privacy arises from the fact that the file you request isn't sent directly to you but through a chain of other systems running MUTE on the Net. This means that for every file delivered, more than one node is labored with the uploading of this file, and given that, for most people, upstream bandwidth is a rather limited resource, the ultimate consequence will be that the system will be slow as compared to one where the files are sent directly, e.g., FastTrack or gnutella.
Is this truly the only Earth I can live on?
Waste doesn't try to hide IPs to keep people pseudo-anonymous. All traffic is encrypted, but you know who is sending it pretty much.
From the log files it seems it wants to connect to monolith.2y.net. At first attempt, this failed to connect to any hosts because I had not setup my router to forward port 4900. Once I did this and manually entered monolith.2y.net under the connections tab, I have 5 hosts listed and a search for mp3 yields some results.
The software seems a little buggy tho. It has crashed twice on me once it is connected to a host and I have only been playing around with it for a few minutes.
telnet://zombiemud.org:3000
Besides which, some clients, such as Shareaza make use of multiple protocols (in this case, BitTorrent, EDonkey, Gnutella, and Gnutella2) in an attempt to unify those protocols. Not a bad idea, really. That said, I'm still waiting for them to add support for the WinMX networks.
--- Bwah?
24.49.37.195 208.191.148.152 131.155.229.140 80.161.130.57 68.49.20.146 216.180.213.130
WASTE, on the other hand, is for small, private networks in which users know or trust each other. Both the sender and recipient know each other's IP addresses. This is far more efficient as users can download files directly from each other.
Both MUTE and WASTE encrypt data, thereby making it far more difficult for ISP's to determine exactly what is being transferred. WASTE has the additional benefit of being a "by invitation only" system - you can't get in unless your public key has been accepted by other users.
There is an algorithm for several parties to have a conversation while keeping the actual sender of each message anonymous.
It is called the Dining Cryptographers Problem.
Sorry Friend, but Mules do KNOW that they are carrying illegal drugs and if they dont they have a defense. In fact that is the defense used in virtually all "courier" cases (as they are called). The Government must prove that they knew they were carrying illegal drugs, which usually isnt hard to prove circumstantially when they swallow condoms of a white powder. It becomes more difficult when it is concealled in toy they say that a relative gave them to deliver. - sometimes they slipup other times they walk free. KNOWLEDGE IS REQUIRED!
Only I have more specific questions. The major problems with WASTE are as follows, in no particular order:
This is the big one. I cannot specify (by public key) who can access an individual shared directory. Since it already doesn't have any anonymity between users of the network, you don't lose anything by implementing this.
WASTE was designed to be used without centralized management, but has no access control. This is dumb. It means that anyone on the network can add people who can then download your files and suck up your bandwidth when you would rather give priority to people you actually know and care about. As such it is only useful amongst very small groups of people who are all good friends.
I plan to test MUTE very soon, perhaps as soon as this evening, but it would be nice to know if any of these problems with WASTE are addressed in MUTE.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Yep. This appears to be correct.
Lalala
Hmm...Downloaded it and installed it, but the seed hosts included with the program, katcher.2y.net and monolith.2y.net are not active on port 4900, which seems to be the default port this protocol uses.
The katcher.2y.net address resolves to 128.114.51.108, and monolith doesn't resolve at all. Reverse DNS lookup indicates that everything in that class C netblock belongs to UC Santa Cruz and nothing in there is talking on 4900. Seeing as how the seeders are not talking on port 4900 and there's no reference on the web pages for more of them, I'm going to guess that this program is more about a proof of concept than a serious contender on the p2p field.
-R
That is, they literally allocate more of the physical line to the downstream channel. At least on ADSL.
This is because people (generally) care much more about how fast their download is than they care about their upload.
They are giving people what they want.
1. Because if we don't, we can be fined, shut down, or go to jail. Yes, really.
2. To stop people from spamming you (intentionally or as zombies).
3. To identify viruses and inform customers (some of them, e.g. Welchia, wreak havoc with an extremely common brand of routers).
4. So our upstream providers don't drop us like a rock when we can't handle abuse reports.
5. For bandwidth metered billing (we don't, some do).
6. So when customer X calls and says "why can't I connect/get a DHCP lease/get to the web/etc" we can actually help them.
7. So we can catch and resolve problems with RADIUS or dhcpd.
If none of the above applied I wouldn't waste the disk space, because it's just not that thrilling to know that user jsmith had IP 1.2.3.4 yesterday at 15:00GMT. Of course, if you're paranoid, feel free to use Freenet, MUTE, or whatever.
These contents may be more useful than the defaults
202.52.36.144 4900
68.61.112.22 4900
24.208.214.50 4900
150.101.30.106 4900
65.71.169.148 4900
68.111.211.154 4900
>efnet #mute-net
/usr/local/bin/bash for MUTE/configure.
The conclusion of everyone who is talking in the channel is that this version is not usable due to frequent crashing. We can't tell if the routing works because the mesh constantly changes as clients crash.
Files are only shared if they are actually in the files directory, it does not search subdirectorys.
The connection list in the program often shows fewer connections than are actually open.
To compile on FreeBSD 5.1, you have to change all 'make' to 'gmake' and remove "typedef int socklen_t" and change the path of bash to
This uses broadcst search. It is disapointing that people keep reinventing the horribly inefficient original gnutella. Broadcast search will severely limit the search horizon (and probably overall size) of a mesh. We need a filesharing program that combines anonymity with an efficient search function, the state of the art is a distributed hash table with querys and results sent by UDP.
It is a pity that this ended up on slashdot now. If this had been announced when a working version is available slashdot might have given it the critical mass of users to get it rolling.
This has lots of potential and will be worth another look when it is stable