Slashdot Mirror

The "real" article is a little more clear than the summary linked here.

The authors claim that a lot of BitTorrent content comes from people who either (a) own a private BitTorrent portal and use it to lure customers (who then share it for free on the rest of the Internet), or (b) promote some for-profit website via the torrent. These websites are promoted by (i) tacking their domain name onto the main download file, (ii) putting the URL into "the textbox" on the torrent search engine (I think this probably means putting the URL into a descriptive text file within the torrent package, which then gets shown as the description on some torrent search engines), or (iii) adding a file to the torrent named after the for-profit website.

I guess the argument is that these 100 users are uploading tons of content in order to get URLs of their own for-profit websites seen by a lot of other users. Then, when the users follow those links, they generate profit for those 100 users, either by signing up for premium bittorrent services or viewing ads on the destination website.
 

There are 100 or so really good proxies out there(maybe tor end nodes?)

Tor would be possible, but tor means that every X minutes you would get a random endnode (it might not be every X minutes, the way tor works in detail is not my area of expertise), which is suboptimal at best for bittorrent. Tor is also more often than not slow, and unreliable for connections that take a long time. Typical use such as HTTP consists of relatively short connections (a few text files, a few binary files for images), but I do have to admit that I don't know if HTTP Keep Alive is respected out of the box by the tor bundles (and I doubt HTTP Keep Alive is such a good idea on an "anonymous" network anyway).

In general, Tor is as reliable as the weakest node in your circuit of nodes you're using as a proxy, which in my experience is not all that reliable at all.

I have no idea what that would do to the torrenting protocol, but it might make it have issues recognizing available resources.

A peer in the bittorrent protocol put simply is a pair of an IP and a port, and it has no trouble distinguishing between other clients on the same IP. It's a little bit more complicated (there's a randomly generated 20 byte ID involved, but as far as I can remember trackers aren't required to send that to other peers in compact mode). Even when you're not using a tracker (by such extensions to the protocol as DHT or PEX), it's still not much of a problem. I've recently spent a bit of time reading up on the protocol (do check out the BEPs if interested, there's some really cool stuff in there) for a little hobby project.

The thing is, without joining the swarm there's really no way to keep track of the peers in the swarm other than by IP and port, and even then. Say for instance you're a member of the swarm and you've got a provider that uses DHCP. The researchers script then does the announce request to the tracker to get a list of peers and among the randomly returned peers is your IP and port number. After about an hour or so, you leave the swarm, shutdown your computer and go to bed. You release your IP back into the ISPs DHCP pool, and 10 minutes later the guy who lives next door turns on his computer and gets that IP. His bittorrent client by default chooses the same port number as you. Suppose that the tracker only returns IP-port pairs in compact mode, instead of the 20 byte id, ip, port triplet, then there is no way for those researchers to see that the peer has become someone else. The chances of this happening are small though, unless it's a really really popular torrent, and even then the handful or random peers returned by the tracker would require quite a bit of luck to have the same peer in it twice on sufficiently large torrent.

Next, even IF the tracker returns the 20 byte id, IP and port triplet, the 20 byteid is supposed to be randomly generated every time the bittorrent client starts. There is an optional field that you can pass as a unique id to the tracker for keeping track of you, but peers in the swarm will never see that. So basically, you can't really tell who is who from IP-port pair. It is a peer, but two different peers over a period of time could be the same person.

Everyone here has probably heard this, but an IP address does not represent a person.

From the press-release from the univesity about the paper:

"In order to remain anonymous, - explains Professor Rubén Cuevas - many of them rent servers from companies that perform this service and then publish contents from those servers".

Are you sure they are renting it, and didn't just script-kiddie their way into the server? Explain to me the logic in paying for something, with mon

Well, cheap+reliable == linux + softraid + Enhanced Network Block Device + Enterprise Volume Management System (or LVM2). It is often faster than non-hw-raid (fake-hw controllers.

I have an ancient laptop with a broken keyboard. The HD/FD are both fine, as are the PCMCIA slots. No CDROM.

What I would like to do is boot a single-diskette that contains enough code to fire up the PCMCIA networking, and either ENBD or something like it.

That way, I could mount the HD in the laptop as a remote block device, and copy an OS across.

Any ideas?

Perhaps doing RAID over network block devices would solve your reliability problem. NBD is designed for RAID, you distribute over partitions that are physically separate from each other on different machines and segments, you can do heartbeat, etc. Don't assume that this is necessarily the "cheap way out with cheap hardware". You can do this with fast hardware that's backed by hardware RAID too and use it in a network RAID 0, 1, or 5 scenario for example.

No. There are patches out there that allow it to be done over the network block driver (nbd) - for example, this one.

what you need can be found here. The enhanced network block device allows you to share a block device, like a ram drive or hard drive, over the network and make it appear on the main machine as a normal hard drive plugged into it. i have created a raid0 over this before. I can't really comment on speed, as it was a 10Mbps network, but it did work. with fast machines and a fast network, i would imagine you would easily saturate gigabit networking.

I must have spent a week working through various docs trying to learn this, and most of what I read was either impossible to understand or just inaccurate. Finally I happened upon this, and I refer to it often. Here's the jist of it:

====================
Introduction
Jail Chroot Project is an attempt of write a tool that builds a chrooted environment. The main goal of Jail is to be as simple as possible, and highly portable. The most difficult step when building a chrooted environment is to set up the right libraries and files. Here, Jail comes to the rescue with a tool to automagically configures & builds all the required files, directories and libraries. Jail is licensed under the GNU General Public License.

Jail program has been written using C, and the setup script has been written using a bash script and perl. Jail has been tested under Linux (Debian 2.1 & 2.2, RedHat 6.1, 6.2 and 7.0 and Caldera Openlinux 7.0), Solaris (2.6), IRIX (6.5) and FreeBSD 4.3. Some people has contributed to jail with patches and ideas. Thanks to all of them.

Jail supports lots of interesting features:

Runs on Linux, Solaris, IRIX and freeBSD (tested) and should run in any of the flavours of these operating systems.
Modular design, so you can port Jail in an easy way.
Support for multiple users in a single chrooted environment.
Fully customizable user shell.
Support for multiple servers: telnetd, sshd, ftpd...
Easy to install thanks to the enviroment creation script.
Should work in any UNIX.
Ease of porting.
Allows run any kind of program as a shell.

An html version of the mailing list has been added to the web site. Now you can read all the user contributions, ideas and patches here.

The toshiba laptop keyboards seem to suffer from a lot of key bounce under linux. On a dual boot setup, the problem only showed up under redhat 7.2 and not under windows 2000.

The problem and a kernel patch are described here. This was the only way I found to fix this problem. I didn't find any "tunable" parameter in config files that would help.

A search for "keyboard bounce" might turn up some more info.