On Wednesday we discussed the open structure of filesharing and its resulting vulnerability to spam. While there are some similarities between e-mail and gnutella spam, the spoof files have no analogue in e-mail. When MediaDefender puts up spoofs for Rihanna’s Disturbia, unless you are using gnutella to search for Disturbia – which you cannot legally do – the spam has no effect on you. But of course, if MediaDefender is allowed to persist in doing this successfully, gnutella would lose much of its appeal.
The solution that has traditionally been adopted is an IP block list. When MediaDefender puts up spoof files, they come from the IP addresses of MediaDefender’s computers. While it is possible that MediaDefender could (and doubtless would have to) get several computers to perform the spoofing, they are all accessing the internet through a single ISP. Therefore, when an ISP is found to be hosting a spoofing operation such as MediaDefender’s, the entire range of IP addresses owned by the ISP is added to filesharing program’s IP block list. When an IP address is on the block list, other computers will refuse to connect to it, thereby preventing it from filesharing.
Because filesharing becomes useless without something to stop spoof files, IP block lists are a common part of P2P sharing programs. Generally, they are posted on web sites and downloaded by the P2P program, at the direction of the user. The program is generally configurable to download the block list from a site of the user’s choosing, and the block list file is stored in a known location and is readable and editable by interested users. For example, this forum discussion describes how to download the block file for the P2P client eMule.
What is not broadly appreciated is the role that LimeWire the corporation plays in the gnutella network. LimeWire is not merely a provider of software (and there are non-LimeWire gnutella clients, not as popular as LimeWire). Limewire’s client software, aside from supporting the gnutella protocol, receives from LimeWire a cryptographically signed file, called simpp.xml. This file contains a number of parameters for the operation of the client, including its IP block list. Because of the strong cryptographic signing by LimeWire corporation, no one else may send the list. LimeWire can therefore, at its sole discretion, block hosts from sending data to essentially all of its clients. Anyone putting up files that LimeWire deems unsuitable is knocked off in a matter of hours, and, since LimeWire is by far the most popular gnutella client, the spoofer is effectively shut down.
The LimeWire P2P clients are unusual in that there is nothing configurable about the choice of block list. Moreover, unlike other programs, there is no way for anyone other than LimeWire to send it, and no way for a non-technical user to examine its contents – in fact, the typical non-technical user would not even know that blocking is going on. (The only way to turn off blocking is on an advanced configuration panel.)
(One other interesting feature is also revealed from looking at the simpp.xml file: LimeWire has added a facility that allows its server, and only its server, to contact a running LimeWire client and ask it various questions about what the client is doing. This feature allows LimeWire to phone up LimeWire clients and inspect them, thereby gathering information about its network. This feature could be used as a sort of mini-spyware, though it is not clear exactly what LimeWire does with it.)
Tomorrow we shall see one way to interpret the legal significance of these behaviors on LimeWire corporation’s part.
I would say that downloading copyrighted content should be considered illegal.
Peter from senuke guide.
IP block list is a great solution, but how can they block millions of IPs?
DD
you might answer the question as to why a legal service would need to use filesharing at all, since if you are paying for content there is enough revenue to cover bandwidth costs. That is how iTunes works and it works fine.I agree with you said. tiffany
IP block lists are notoriously ineffective (and overbroad) mechanisms for controlling spam, and there’s no reason to think they will be any better where P2P spoofing is concerned. (After all, last I checked, it was pretty easy to spot spoofs in search results thanks to the large numbers of servers and identical copies that spoofers used. And, of course, spoofing costs money, which means the labels tend to do it only for a tiny fraction of the catalog.)
Real resistance to spoofs comes from having a hash that users are willing to vouch for. And there is no reason that this mechanism needs to be built into a file sharing application, rather than provided by independent third parties (see, e.g., the metadata collected at MusicBrainz). That’s part of the reason Bit Torrent has been so successful — the hash checking plus community vouching makes it very hard to spoof.
I think you can expect more developments in this direction, rather than in IP block lists.
I almost always find this blog interesting and informative, and this investigation into a particular P2P implementation has already been especially enlightening to me. You’re not even done, and I feel much more informed about this topic. Thank you. I look forward to the rest.
search for Disturbia – which you cannot legally do
This may be a bit pedantic and IANAL, but I don’t think actually searching for unauthorized content is illegal, it’s what you do after you find it that could be. I question whether any court has found the act of downloading unauthorized content to be illegal either. All the court cases that I have read about have been against people whose computers have been uploading or sharing such content, and while the RIAA usually mention downloading in their complaints it’s the sharing that they’re actually prosecuting. They don’t seem to have been targeting downloaders who don’t share, even though it might be easier for them to find downloaders (by sharing the tracks themselves and recording the IP addresses of everyone who downloads from them). While the default setting for many P2P clients might be to automatically share everything they download, we should be careful to distinguish between the two when discussing the issue.
I wouldn’t be so quick to assume that current file-sharing (distributed systems) technologies are the state of the art and therefore to make far reaching deductions from the nature of the current implementations.
This is because the state of the art that would by now have developed cannot develop in a legal environment that is antipathetic toward it. Who will fund the development of such systems if the developers are liable to prosecution? Many of the design decisions of the current implementations are directed by legal rather than technical considerations.
A legal file-sharing system that must check licenses or pay fees each time a file is replicated or distributed is akin to a car that must be preceded by a pedestrian carrier of a red flag.