Thanks for your quick reply. I have a few questions - > * This will not solve freenet's problems with hostile environments. While you're certainly right in that this is no panacea, it does allow people behind a firewall, an HTTP proxy, or a NAT to have more reliably anonymous publication and retrieval of content. The use of public FProxies right now leaves people open to attacks both by sniffing the connection between the FProxy and the browser or by submitting/retrieving content to a compromised FProxy. Obviously, freenet was designed to afford a different level of anonymity than fproxy. I'm just saying that today, there are people using public proxies to access freenet, and it would be good if there was a way to serve their needs (retrieve/publish content anonymously) without requiring them to have administrative control over their network. > Freenet requires "path folding" for acceptable performance. In the general case of the arbitrary sets of nodes A and C with B serving as a bridge, you're absolutely right. If, however, the size of the stored content in A was significantly smaller than the content in C (as would be the case of a lab of nodes (A) bridged out to the full freenet (C)), wouldn't fred automatically route almost all of A's requests through B? And, given B having such a solid routing table to A (since most nodes in A would eventually have a direct route to B), wouldn't that reduce the depth requests from C that happened to be passed on to B would have to travel to reach A? Wouldn't B learn enough about all of the nodes in A to be able to make some pretty good routing estimates in response to queries from C to deliver it to the right node in A in near constant time? My concern is to find a way that people with limited network access (baseline of being able to initiate HTTP GET+POST requests) can retrieve and publish with the anonymity along the lines of other freenet users. People behind one of these bridges wouldn't require the same performance as the rest of the freenet nodes would. I would assume that people with such access would be satisfied with something as slow as an email to freenet gateway, if it would provide them with the anonymity and plausible deniability that freenet does. Of course, this does adjust the routing characteristics of any node in C that has a route to B, as B would respond significantly slower that other nodes in C, but those nodes should currently be able to handle slow nodes or network connections. And since some requests could be sent to B (and therefore bridged to nodes in A), its plausible that content stored on a node in A is not there due to their requesting of it. Is your performance concern regarding the access speed of users in A, or in the damage it might do to the routing of nodes in C? > This means that even with steganography, if freenet is illegal in a > given area, the authorities will be able to eliminate it. I'm not sure I follow. Of course, if the threat model is such that everyone literally has the police watching over their shoulder as they type, no one is secure. I know my mention of stenography was wild blue yonder, and probably not even useful anytime soon. I was just mentioning that as a way in which a bridge could be adjusted to hide the FCP-esque messages via stenography. But this group of course had already though of that and had rightly pushed that off to v1.0 (or even v3.0). > This is post-1.0 stuff, sorry. By this, do you mean FCP isn't frozen enough for another application to be written without having to frequently take into account protocol changes? Or that the existing codebase isn't stable enough to use as a base for the development of a bridge? Or that the developers working on fred/freenet have more pressing needs to attend to (which is certainly true)? tia, -jrandom (and sorry for the signature on my last message... this webmail client strips blank lines, destroying the integrity of the signature)
!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+ CryptoMail provides free end-to-end message encryption. http://www.cryptomail.org/ Ensure your right to privacy. Traditional email messages are not secure. They are sent as clear-text and thus are readable by anyone with the motivation to acquire a copy. !+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+ _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
