Michael Yip wrote:
> Evan Daniel wrote:
>   
>> On Sun, Aug 23, 2009 at 5:19 AM, Michael Yip<mhy...@cs.bham.ac.uk> wrote:
>>   
>>     
>>> Dsoslglece wrote:
>>>     
>>>       
>>>> Michael Yip a écrit :
>>>>       
>>>>         
>>>>> Hi,
>>>>>
>>>>> My name is Michael and I'm currently studying the source code of Freenet.
>>>>>
>>>>> I have found that the object reference for all PeerNode objects has the
>>>>> IP address of the peer associated with it. How is anonymity kept with
>>>>> the IP of the peer exposed? I have examined the log file and it seems
>>>>> the object reference of the peers are logged as they are added.
>>>>>
>>>>> What I'm confused is since Freenet seek to promote freedom of speech in
>>>>> the presence of strict government control, if they decide to run a
>>>>> Freenet node and collect IP addresses in this manner, the consequences
>>>>> would be unthinkable....
>>>>>
>>>>> I have tested this by adding another node of mine and my IP address
>>>>> appears as expected.
>>>>>
>>>>> Can anyone explain to me why??
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Michael
>>>>> _______________________________________________
>>>>> Support mailing list
>>>>> Support@freenetproject.org
>>>>> http://news.gmane.org/gmane.network.freenet.support
>>>>> Unsubscribe at 
>>>>> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
>>>>> Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
>>>>>
>>>>>
>>>>>
>>>>>         
>>>>>           
>>>> Hi Michael...
>>>> it is correct that your IP would be known by your neighbour node, but,
>>>> he is the only one to be able to identify you... more, and beside the
>>>> fact of being able to be sure that you are using Freenet (only sure of
>>>> this), even so, he has no way of knowing if the info or file or
>>>> whatever, coming to you, or going from you, did or not come or go 10
>>>> nodes away from you, since you act also (as a node) in passing
>>>> packets... and anyway, even so, he is (and you are, and any of your
>>>> neighbours) unable to know the content of the package, if you didn't
>>>> create it yourself or ask yourself for it since only the original
>>>> sender and final receiver are able to know it's content.
>>>> Hope it was clear...
>>>>
>>>>
>>>>       
>>>>         
>>>    Hi,
>>>
>>>    Thanks for your reply.
>>>
>>>    Taking from the point that IP addresses are known to your peers, I
>>> have another question.
>>>
>>>    I've noticed that the hop-to-live counter is decremented according
>>> to the policy of:
>>>     1)  the source node of the request,
>>>     2) the node which recently reported fail for a data request or
>>>     3) the node handling the request (usually because the node is the
>>> source of the request)
>>>
>>>    Ok, so what if I modify the code for my node so that:
>>>
>>>    1) maxHTL = 1
>>>    2) decrementAtMin = false
>>>    3) disableProbabilisticHTLs = false
>>>
>>>   Would this mean that my peers would not forward my message any
>>> further? This is because if so, this would allow me to probe my peers
>>> using my set of keys for data....
>>>     
>>>       
>> Your peers will sometimes pass on requests at min htl, specifically to
>> avoid this problem.  That's what the probabilistic htl thing is for.
>>
>> Turning off probabilistic htl only turns it off on your node; it
>> doesn't change your peers config, obviously.  So turning it off will
>> let other people probe your store, but doesn't help you probe theirs.
>>
>> Evan Daniel
>>   
>>     
> Hi Evan,
>
> But what I've found from the source code (the Node class and the 
> RequestSender class) is that the HTL of a request would actually be 
> decremented according to the SOURCE of a request (that is, if a source 
> exists e.g. the node is forwarding a request). Also, it could also be 
> decremented according to the most recently failed node if the request 
> has been forwarded beforehand. Only if neither exists would the request 
> be decremented according to the node handling the request.
>
> This is at least as far as I understand from the source code so if 
> anyone can point out otherwise, I would be glad to hear it.
>
> Thanks,
>
> Michael
>
>
>   
>> _______________________________________________
>> Support mailing list
>> Support@freenetproject.org
>> http://news.gmane.org/gmane.network.freenet.support
>> Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
>> Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
>>   
>>     
>
>   
Hi all,

After examining the source code further, I have found that the peers of 
a node which are represented by the class PeerNode, have their own set 
of probablistic HTL factors.

Such factors (decrementHTLAtMaximum and decrementHTLAtMinimum) in the 
PeerNode DO NOT actually follow the factors of the peers they represent.

This means that each Freenet node actually has full control over how it 
decrements the HTL of the requests that it processes. This means that 
the peer which sent the request has no control over how the HTL of that 
request is to be decremented at the destination node. Thus, a node 
cannot probe by setting its maxHTL value to 1 and disableProbablisticHTL 
= true.

Can anyone please confirm this for me?

Thanks,

Michael
> _______________________________________________
> Support mailing list
> Support@freenetproject.org
> http://news.gmane.org/gmane.network.freenet.support
> Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
> Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
>   

_______________________________________________
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe

Reply via email to