Hi, I'm new to the freenet development effort, but I consider this project to be very important for the sake of freedom on the internet, so I wish to contribute, eventually code, but for now I'll criticize.
I'm not sure if version 1.0 of the protocol as published on the web site is the most up-to-date version. If there is a more recent version available, could someone please point me at it. I would like to know why it was chosen in sections 3.1.3.2 and 3.1.3.3 that HTL and depth should not be updated with a probability of 40%. Obviously, 0% is wrong and 100% is very wrong. Without any further knowledge of the optimum value, I would pick 50% as the optimum value to quote in the spec (obviously node operators can ignore the spec, but it should be in their best interest not to). I know a little about information theory and consider 50% to be a somewhat magical probability. I'm worried that someone might find a statistical attack on freenet that depends on the asymetry of 40/60. Unless someone has some proof that 40/60 is closer to being optimal than 50/50, you should quote 50/50 in the spec. If I can think of a better reason why, I'll post it here. Related to these probabilities is the issue of how to initialize HTL when replying to a request with Data.Send (section 4.4.1). Ignoring for the moment the recommended addition of a random number to the Depth of the request, there is a certain probability that the Depth of the request is too small. Offsetting this is the probability that the Send.Data reply will outlive its HTL. I figure the probability of a Send.Data message not surviving all the way back to the originator of the request is 1 in 3*2^r, where r is a small constant added to HTL when initialized (I used the 50/50 probability described above). Therefore, to ensure that no more than 1 in 3072 messages, say, fail to make it back, choose r=10 (ie. HTL = Depth from request + r). r=10 is just a suggestion here. A small random constant can also be added in to obscure the source of the data. Unless I'm misunderstanding something, this information should appear in the spec. Another concern is with section 4.4.2: If it does choose to locally store the data, it may wish to replace the node address in the DataSource with its own. Nodes should do this with some random probability to help disguise the original source of the message. One suggested way to do this is to replace the DataSource value with the persent node's address with a probability of 1 divided by the value of the Depth header field. I have a suggestion. How about nodes replace DataSource with their own address with a probability of 50%? It should be the goal of freenet to not propagate the source address of the data too far. With a 50% probability you get a 50% probability of propagating beyond the first node, 25% beyond the second, 12.5% beyond the third, and so on. There has been talk about nodes temporarily replacing DataSource headers with their own adress with probability 1 to bootstrap themselves into the freenet. 50% should be enough to get most nodes involved quickly so this bootstrapping idea shouldn't really be necessary. I'm not sure, but I suspect the current protocol works differently for nodes vs. clients. For improved anominity, clients should appear to nodes as other nodes (I realize people are encouraged to run their own nodes, but that may not be enough). This idea has an obvious problem steming from the fact that clients are transient and nodes who store a clients address as DataSource will later have problems trying to contact the non-existant node. Not propagating DataSource too far as described above would help with this problem. What do others think about this? The final issue I would like to raise is concerning meta data. I think all meta data (public and private) needs to be protect by the CHK and nodes should be discouraged from passing any meta data not protected within the CHK. I'm worried that without this condition, meta data can be added, altered, and deleted by nodes at will as the document is passed around. The only meta data (outside the CHK) passed along with a document should be the CHK itself, the document size, and DocumentSource (limited as discussed above). All other meta data should be appended by the document creator and rendered invarient from then on. If this is already the case, just ignore me as I misread the spec. I hope I'm not out of order here. I'll try to post in small chunks in the future. Thanks. Chris. _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev