Quote:
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.
Quote:
| 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.
Quote:
| 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.
Quote:
| 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.
Quote:
| 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.