[freenet-support] 0.7 public alpha imminent!
One issue that might need consideration is the extensibility of the network when a public alpha version is released. Currently, each node has a hard-coded limit of 20 opennet connections. These slots are, at least on my nodes, all filled up on nodes connected to the network. Now if this is also the situation with the seednodes, how do newcomers integrate into the network? Or will newcomers form a new, disconnected outer layer? This would especially be an issue after a slashdot. IMO there would be need for hub -nodes, that are well connected to the network, and which have a flexible amount of connections. The nodes would cut off nodes based on some algorithm based on the usefulness of a link (data transferred, success rate, etc.). However, the nodes would always allow new connections, and only after some time enter the new connections into the competition of the necessity of the link. The darkent/opennet structure could have fullfilled this need, with the darknet building persistent connections that form the core network, and an opennet for newcomers to find more permanent links. However, there is currently no mechanism of moving opennet connections to darknet, or make them otherwise (semi-)permanent, or is there? -- Malkus Lindroos Matthew Toseland wrote: > Hopefully we will release a second public alpha of Freenet 0.7 next week. > Please test Freenet, and reply to this thread with any bugs that you think > need to be fixed urgently. > > > > ___ > Support mailing list > Support at freenetproject.org > http://news.gmane.org/gmane.network.freenet.support > Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support > Or mailto:support-request at freenetproject.org?subject=unsubscribe
Re: [freenet-support] [Tech] Some issues and considerations
Hi Stephen, In the UK, a new law has been brought in which would make it a crime for a suspect who has encrypted data on his computer to fail to reveal the password to the police. The police can only issue a disclosure order if they believe on reasonable grounds... that a key to the protected information is on the possession of the person in question. I'm not a lawyer but that suggests a defence on the basis that you don't have, and have never had, the key in question. http://www.opsi.gov.uk/acts/acts2000/ukpga_2023_en_8#pt3-pb1-l1g49 And in the USA, users with encrypted content are curently protected by a constitutional right to privacy which prevents police from compelling them to disclose their passwords. But right now even that right is being put into question with an important test case taking place (see link below)... The test case relates to users who know a password but refuse to disclose it; it does not relate to users who don't know a decryption key (which would be too long for most people to memorise anyway). It is also important to point out that at least in the USA the NSA avails itself to the use of advanced programs that can carry out advanced 'dictionary analysis' to permute nearly every possible combination of letters and numbers for a 'brute force' attack to discover the password for an encrypted file - a process that can take years. Again, this is not strictly relevant - a password can be cracked using brute force, but a 256-bit encryption key can't. Secondly, there are government installations in the UK (for instance a new MI6 building on the London enbankment, which has the national internet traffic channeled through it) which carry out surveillance of communications including internet communications. This surveillance includes not just keyword profiling but also several other different kinds of intelligent and statistical analysis of the traffic itself, even where encrypted files are involved, and an significant intelligence perspective can be obtained in this way. Yes, traffic analysis is a very important issue. Freenet does its best to frustrate traffic analysis by using a transport protocol with no unencrypted header fields, delaying and coalescing small packets to disguise timing patterns, and padding packets to disguise the size of the payload. Nevertheless I'm sure it's possible to design a rule for a deep packet inspection engine that will identify Freenet traffic. A possible direction for future research would be hiding Freenet traffic inside other application-layer protocols (HTTP, BitTorrent, RTP etc). Cheers, 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:[EMAIL PROTECTED]
