Comment how to solve the file verification problem (Score 1) 391
it won't solve the legality problem, but here's a simple solution to the file test problem. it's obvious, really.
wrt checksums, i agree you can't really trust the person you're trying to donwload from. however, you have partially seen a solution with judges, you just haven't gone far enough with the idea.
consider a new kind of P2P ... dual channel.
channel A = b/w for transfer of files.
channel B = judge traffic.
now consider three machines, X, Y, and Z. X wants to get a file from Y, but wants to be sure the file Y is sending isn't hacked in some way. so X randomly picks a new machine, Z, and asks Z if it believes Y has an authentic copy. X thinks the answer is 'yes' (default) since it has no information about the machine Y. Z also has no information about Y, so it says yes as well with non-authoritarian response (default).
now there are two cases. Y sends a valid file, or Y doesn't.
case 1: Y sends a valid file. X receives the file into the queue "untested". when X checks the file, the file is either marked Valid or Invalid. on a Valid, X notifies Z that the file was correct, and everything is ok. X and Z now have hard data and can provide an authoritarian response to any queries about machine Y.
case 2: Y sends a bogus file. repeat scenario, but notify fake. now X and Z know that Y is sending fake files.
how does this solve the problem? obviously, you begin to propagate truth through the system. machines that can't be trusted don't get traffic. you can obviously increase the number of machines in the discussion(s) for judging and broadcasting results.
to avoid spoofing the judge channel, no "notify" events of a judge result can take place without a corresponding query first. spurious 'valid' postings are tossed, and perhaps chalked up as hard evidence of a rogue system and hence untrustworthy.
this scheme works, but has one weakness: multiple machines can directly target the P2P network. here, RIAA machine A and B work in tandem. for every x in P2Pnet, A queries x about B, then A sends to x that B is good.
while this is a valid weakness, it's also a _short-lived_ weakness. by factoring in negative results at a higher weight, and keeping a history for some amount of time T, it becomes clear that negative feedback from bad files at certain machines will push through the network.
if a negative event has 3x the weight of a positive event, then these deliberate attacks can only succeed for a short period until sufficient negative feedback is in the network. by making T large enough, those machines involved in the rogue entries will be denied from further efforts (since it's IP based, not name based).
anyone see any weaknesses with this idea?
wrt checksums, i agree you can't really trust the person you're trying to donwload from. however, you have partially seen a solution with judges, you just haven't gone far enough with the idea.
consider a new kind of P2P
channel A = b/w for transfer of files.
channel B = judge traffic.
now consider three machines, X, Y, and Z. X wants to get a file from Y, but wants to be sure the file Y is sending isn't hacked in some way. so X randomly picks a new machine, Z, and asks Z if it believes Y has an authentic copy. X thinks the answer is 'yes' (default) since it has no information about the machine Y. Z also has no information about Y, so it says yes as well with non-authoritarian response (default).
now there are two cases. Y sends a valid file, or Y doesn't.
case 1: Y sends a valid file. X receives the file into the queue "untested". when X checks the file, the file is either marked Valid or Invalid. on a Valid, X notifies Z that the file was correct, and everything is ok. X and Z now have hard data and can provide an authoritarian response to any queries about machine Y.
case 2: Y sends a bogus file. repeat scenario, but notify fake. now X and Z know that Y is sending fake files.
how does this solve the problem? obviously, you begin to propagate truth through the system. machines that can't be trusted don't get traffic. you can obviously increase the number of machines in the discussion(s) for judging and broadcasting results.
to avoid spoofing the judge channel, no "notify" events of a judge result can take place without a corresponding query first. spurious 'valid' postings are tossed, and perhaps chalked up as hard evidence of a rogue system and hence untrustworthy.
this scheme works, but has one weakness: multiple machines can directly target the P2P network. here, RIAA machine A and B work in tandem. for every x in P2Pnet, A queries x about B, then A sends to x that B is good.
while this is a valid weakness, it's also a _short-lived_ weakness. by factoring in negative results at a higher weight, and keeping a history for some amount of time T, it becomes clear that negative feedback from bad files at certain machines will push through the network.
if a negative event has 3x the weight of a positive event, then these deliberate attacks can only succeed for a short period until sufficient negative feedback is in the network. by making T large enough, those machines involved in the rogue entries will be denied from further efforts (since it's IP based, not name based).
anyone see any weaknesses with this idea?
