Spoof File Preventiton features

I find it sad that the RIAA and MPAA are now trying to flood P2P networks with spoof files, that look like songs and moviesbut are not. Instead, they contain silence and 30 second repeats of audio.

I have given this some thought, and here are some things that could counter their "spoof" and "interception" attacks.

1) To counter their "spoof" attacks, add a rating feature where users can rate files.

2) I also suggest a feature that can block files from being indexed with certain checksums. A spoof files checksum is likely to be much different than a real songs checksum.

To counter the proposed "denial of transfer attacks", I propose a system that a user can block certain IP or Mac addresses from beign indexed, or connecting to, or getting directory searches.

Also, a system of four requests maximum for the same file from the same computer, should also ban their IP, and download and IP input proirity should be given to other hosts.

3) To counter the "intercept" technique, would take some encryption on the transfers and/or directory system, so the automated dectors could not filter the search or file being transfered. I suggest each machine having a different key that is random.

I did a search on the network tonight for the word "strata" and found these results:

!!YES!!_strata zip 296KB T1
!!YES!!_strata rar 288KB T1
!!SETUP!!_strata exe 251KB T1

which I thought a little odd.

then I did a search for "markz" and got these results:

!!YES!!_markz zip 296KB T1
!!YES!!_markz rar 288KB T1
!!SETUP!!_markz exe 251KB T1

I can only assume these files will install porn spyware or some such thing if you download them. Since I refuse to download them I can only assume.

But I think this is what you are referring to as "bogus files" or "intercepts" isn't it.

[Patchmaster]

Originally posted by StephenH
1) To counter their "spoof" attacks, add a rating feature where users can rate files.

Just delete the files that are crap. Why leave it around for someone else to download? Keeping these files available for download does nothing but assist the RIAA in their spoofing.

2) I also suggest a feature that can block files from being indexed with certain checksums. A spoof files checksum is likely to be much different than a real songs checksum.

I'd suggest a slightly different spin on this. Add a feature that allows you to mark a file as "trash". This will delete the file from your system so you aren't bothered with it and no one else can download it from you, but LimeWire keeps the file hash info and warns you if you attempt to download this same file again in the future. I suppose it would be possible to share your "trash hash", but I think that might create more problems than it prevents. It would be too easy to create such a file with lots of good file signatures in it and thereby prevent you from getting files you really want. Each person creating and maintaining their own "trash hash" would probably be the best way to go.

To counter the proposed "denial of transfer attacks", I propose a system that a user can block certain IP or Mac addresses from beign indexed, or connecting to, or getting directory searches.

This is already available, at least in the beta I downloaded the other day. It would be nice if there were an easier way to get IPs into the list, but I'm sure they'll eventually get around to that. The only problem here is with dynamically assigned IPs. Ban a bad guy one day, the next day he's got another IP and some innocent soul who's done nothing to you has been banned.

Also, a system of four requests maximum for the same file from the same computer, should also ban their IP, and download and IP input proirity should be given to other hosts.

I think that's a bit excessive. There are too many problems with dropped connections and various other nasties. Maybe X requests within a certain time period. At the very least, someone who sends four requests in five minutes is being a pest, even if they don't mean to be.

3) To counter the "intercept" technique, would take some encryption on the transfers and/or directory system, so the automated dectors could not filter the search or file being transfered. I suggest each machine having a different key that is random.

I think this would defeat the ultrapeer stuff, though your suggestion is worth further discussion. Have the requestor provide a public key with the search request. The responder would encode the response so everyone it passes through is not able to read it. The requestor decodes it. I'm not enough up on encryption techniques to know if this would work, especially since all the intervening nodes would know the public key that came with the request.

[MacTerminator]

There have been a lot of posts recently about the annoyance caused by spammers, bots and RIAA sabotage attempts. The simplest solution to implement would be to be able to paste or load text files into the host filter list so that users could share non-grata IP lists on the net. I would guess that most of worst hosts will be on high-bandwidth, fixed-IP connections so I think this measure would be reasonably effective.

At a later stage a 'spam-cache' feature could be added which would automatically update the filter host list with newly identified anti-social IPs each time LW starts up. I know that some other clients have already introduced features of this type.

[Joe Cuervo]

...LimeWire keeps the file hash info and warns you if you attempt to download this same file again in the future. I suppose it would be possible to share your "trash hash"

Hashing won't work because the RIAA will just serve a slightly different file every time.

The only way is to have a list banned IP addresses and propagate it across the networks.

After that the problem will be how to avoid the fake lists the RIAA is putting on the network.

After that.....well... who knows.


As for spammers, you have to detect nodes which reply to *anything* by sending them random text and seeing if they say they've got it.

eg. I ask for "iudshfiushdfh"

If they reply !!YES!!iudshfiushdfh.mpg then they're a spammer.

Originally posted by Joe Cuervo
Hashing won't work because the RIAA will just serve a slightly different file every time.

The only way is to have a list banned IP addresses and propagate it across the networks.

And what's to stop them from serving up a slightly different IP address every time?

A shared list of banned IP addresses is a bad idea. Dynamic IPs change regularly. You can argue the bad guys aren't likely to use dynamic IPs, but if they're smart enough to do all the other stuff that's alleged it certainly won't take them long to start changing IPs. Plus, a shared list is just begging for problems. Someone with a grudge will start adding IPs just to get back at people. And the bad guys could simply add the IPs of people sharing tons of files. Then we'd all end up banning the wrong people.

[MacTerminator]

At the moment, I have a reasonable number of IPs in my filter host list and this seems to significantly reduce the number of spam/bot results. I'm sure that experienced users that visit this forum would have a whole load of bad IPs they could add and if these lists were vouched for by respected users/developers on Gnutella forums, I don't see a problem.

However, I totally agree that in the medium term, banned IP lists will probably cease to be effective as the bad guys introduce dynamic/false IPs - if they haven't already started doing so.