|
Peer to Peer The 3rd millenium technology! |
|
Thread Tools | Search this Thread | Display Modes |
26-06-02, 02:26 AM | #21 |
- a rascal -
Join Date: Mar 2002
Location: for security reasons, never the same as the President's
Posts: 759
|
I leave the Underground for a couple of days (work deadline and a killer heatwave), I come back.... and I find a brand new p2p app - dedicated to me
I love you guys! Now for the nitty-gritty: Anonymity: will that be IP bouncing? Jack mentioned that Freenet has that, but I don't think it does. From what I remember Freenet only provides deniability: someone can still do an IP trace on something back to you, but the nature of Freenet means you can (sometimes) honestly say you didn't know the material in question was on your PC, as the program/network archived material in encrypted form 'published' by someone else. AFAIK only Filetopia has IP bouncing, and only then as an add-on, and you have to find & connect to a specific 'bouncer' to use that feature. As the main oppression tactics of the copyright-exploiters are: 1. intimidate/attack the p2p app makers, 2. IP trace and intimidate the p2p sharers & their ISPs, IP bouncing is the way of the future in p2p. (BTW, did you relocate to Sealand yet, AYB? you don't want to end up like AG...) .NET vs. Java I don't really have a clue on the various merits of each... which is exactly why my opinion on it matters! The vast majority of potential F-U-RIAA sharers won't know either, but they will know that Java has been out for a while, is tried & tested and that they probably already have it. Do they really want to install some life-altering 'framework' just to try out one new p2p app? Prolly not. In a few years time when .WTF is well-known and installed by default in newborn children, it won't be an issue having the app coded in .WTF. But for now, I am glad (and, yes, a little proud <sniff>) that you have chosen the Java route. Now I just need to get my hands on your new app. Congratulations, best wishes and many happy returns on your app's 'birthday'! And remember, folks... just say: "F U RIAA!"
__________________
Your prompt response is requested. Respectfully, Mark Weaver, Director of Enforcement MediaForce, Inc. (212) 925-9997 |
27-06-02, 09:36 AM | #22 |
Registered User
Join Date: Jan 2002
Posts: 82
|
Well work is coming along nicely
I honestly haven't looked at how we will achieve anonymity yet as its quite a ways down the road at this moment in time. As far as getting attacked ourselves, with the initial release simply connecting to other networks we have very little to worry about. And as I've said b4 if there is any danger of us being closed down we will make our project open source (if it isn't already) |
27-06-02, 02:00 PM | #23 | ||
Guardian of the Maturation Chamber
Join Date: May 2002
Location: Unimatrix Zero, Area 25
Posts: 462
|
Quote:
Personally, I think that an app with a built-in web community (eg. bitzi comments, hashlinks & forums) is the best solution right now. If people could easily find ways around fakers, viruses etc. ,while learning about their favourite client, their computer & their fellow netizens, it would encourage them to become better members themselves. This would have a beneficial ripple-effect on all the communities/networks they participate in. When I first started using FT clients, I was only interested in the content. It didn't occur to me that a community even existed! This is why it should be easily accessable from the client-side. Plus, many clients with strict anti-leeching policies are failures. I suggest reading this article posted by naz yesterday. Also, you shouldn't neglect the fact that many people enjoy multiple accounts & the anonymity that today's p2p clients offer. This does cause problems as far as fakers, virus sharers & spammers are concerned. However, it does attract many decent citizens who might not otherwise participate out of concerns for the snooping phenomenon. Quote:
I'm going on a bit now, but another feature that I believe is important is priority. If a rare file is available, I want it to receive the utmost attention! Another thing I hate is when a common file is 99% complete, yet the client starts downloading another queued file from 0% because the temporary file is alphabetically prioritised or some other arbitrary reason! Priority for uploads is another way to ease the distribution of rare material. Right now, it requires manual editing of shares or moving partial downloads. Finally, I think that embedded metadata, although useful, can lead to "fragmentation" of distribution. People change filenames or tags all the time for selfish reasons, without re-encoding or otherwise editing the actual contents. Swarmed downloads can become irrelevant in some of these scenarios, as hashes are based primarily on filesize (which is altered slightly when tags/filenames are changed) as well as type & name. If only multi-source downloads could actually use all the sources available & you could change the details once it completes. If you could develop a hash which ignores tags, as well as one which includes them (2 hashes per file), this might be somewhat phenomenal! Another way around this problem would be to use a simple external database (.xml file for example) which overlays details onto files for searches. The only problem is this wouldn't be compatable with most external audio/video players. We need a change in standards before this might be feasible! As others suggested, sharing of partials is another solution, but I don't think it's enough when dealing with high-speed leechers. Okay, that's all. |
||
27-06-02, 02:10 PM | #24 | |
Join Date: May 2001
Location: New England
Posts: 10,024
|
Quote:
- js. “The primary goal for Freenet security is protecting the anonymity of requestors and inserters of files. It is also important to protect the identity of storers of files. Although trivially anyone can turn a node into a storer by requesting a file through it, thus ``identifying'' it as a storer, what is important is that there remain other, unidentified, holders of the file so that an adversary cannot remove a file by attacking all of the nodes that hold it. Files must be protected against malicious modification, and finally, the system must be resistant to denial-of-service attacks. Reiter and Rubin present a useful taxonomy of anonymous communication properties on three axes. The first axis is the type of anonymity: sender anonymity or receiver anonymity, which mean respectively that an adversary cannot determine either who originated a message, or to whom it was sent. The second axis is the adversary in question: a local eavesdropper, a malicious node or collaboration of malicious nodes, or a web server (not applicable to Freenet). The third axis is the degree of anonymity, which ranges from absolute privacy (the presence of communication cannot be perceived) to beyond suspicion (the sender appears no more likely to have originated the message than any other potential sender), probable innocence (the sender is no more likely to be the originator than not), possible innocence, exposed, and provably exposed (the adversary can prove to others who the sender was). Against a collaboration of malicious nodes, sender anonymity is preserved beyond suspicion since a node in a request path cannot tell whether its predecessor in the path initiated the request or is merely forwarding it. Protection for data sources is provided by the occasional resetting of the data source field in replies. The fact that a node is listed as the data source for a particular key does not necessarily imply that it actually supplied that data, or was even contacted in the course of the request. It is not possible to tell whether the downstream node provided the file or was merely forwarding a reply sent by someone else. In fact, the very act of successfully requesting a file places it on the downstream node if it was not already there, so a subsequent examination of that node on suspicion reveals nothing about the prior state of affairs, and provides a plausible legal ground that the data was not there until the act of investigation placed it there. Requesting a particular file with a hops-to-live of 1 does not directly reveal whether or not the node was previously storing the file in question, since nodes continue to forward messages having hops-to-live of 1 with finite probability. The success of a large number of requests for related files, however, may provide grounds for suspicion that those files were being stored there previously. The Freenet network provides an effective means of anonymous information storage and retrieval. By using cooperating nodes spread over many computers in conjunction with an efficient adaptive routing algorithm, it keeps information anonymous and available while remaining highly scalable. Initial deployment of a test version is underway, and is so far proving successful, with tens of thousands of copies downloaded and many interesting files in circulation. Because of the anonymous nature of the system, it is impossible to tell exactly how many users there are or how well the insert and request mechanisms are working, but anecdotal evidence is so far positive. We are working on implementing a simulation and visualization suite which will enable more rigorous tests of the protocol and routing algorithm. More realistic simulation is necessary which models the effects of nodes joining and leaving simultaneously, variation in node capacity and bandwidth, and larger network sizes. We would also like to implement a public-key infrastructure to authenticate nodes and create a searching mechanism.” http://freenetproject.org/cgi-bin/twiki/view/Main/ICSI |
|
19-08-02, 06:11 PM | #25 | |||||||
Madame Comrade
Join Date: May 2000
Location: Area 25
Posts: 5,587
|
Hi SA_Dave and thanks for your good post!
Quote:
Quote:
To start off, there is no need for any single peer to keep a complete index of all identities in the network. In fact this is impossible in a decentralized network where new identities appear and old ones disappear in an unpredictable way in different parts of the network. We don’t need to know and memorize the identities of a million peers that form the network but rather the identities of a few dozen peers that are on our hotlist and ignore list. In addition we might want to memorize the identities of say 1000 of our last file transfer contacts (so that we could reward sharers and restrict leeches). Instead of having a fully connected PxP identity matrix (P being the population) we are having a sparsely connected network of P nodes, not unlike the brain where each neuron is connected only to a very small fraction of the entire neuron population. The technological challenge is to develop an architecture that implements this in the decentralized environment. Quote:
Quote:
Quote:
Identity management is a separate question but has an important impact on community tools and activities as the quality of identities determines whether trust mechanisms can be implemented in the groups or not. Quote:
Quote:
- tg |
|||||||
Thread Tools | Search this Thread |
Display Modes | |
|
|