On Friday 07 August 2009 12:08:39 Alex Pyattaev wrote: > Hm, blocking IRC is shit. My employer used to block ICQ. > And, I did not know about situation in Iran. If it is that bad, then maybe > we should really consider tunnel solution. However, we should consider > making such tunnel traceable from the exit side(by the tunnel provider), > since this would decrease the probability of use of such tunnels by > international criminals (IMHO, we should not support them)
In the current proposal, it is traceable: Anything exiting the exit node will have entered through one of his friends. If we allow forwarding to some depth, it is a larger circle of friends. As with any out-proxy there are legal issues - namely that if your friends access child porn through your proxy, you are likely to have a dawn raid and your computer seized and not returned for several years. So you should pick your friends wisely! > > On Fri, Aug 7, 2009 at 12:39 PM, VolodyA! V Anarhist < > [email protected]> wrote: > > > Alex Pyattaev wrote: > > > Hm, Colin, probably you are right. Those who actually need a tunnel can > > > set it up theirselves anyway (e.g. via SSH). And those who can not set > > > up a tunnel via ssh, probably will be happy with zero-configuration > > > proxy for web access. > > > And, there is an political issue about tunnels to the internet from the > > > freenet. Now it is impossible to use freenet as a massive anonymous > > > proxy. Probably, that's for good, since the first people to use such > > > system would be hackers and spammers, who actually need to have full > > > anonymous access to the internet. > > > So probably it is better to leave it "just HTTP" for now. > > > > My university is blocking IRC (via a packet shaper), so when i have heard > > of > > that idea that was the first thing i thought about. > > > > While i do agree that perhaps we should allow every protocol to pass > > through, > > limiting it only to HTTP is too much i think. > > > > - Volodya > > > > > On Thu, Aug 6, 2009 at 9:48 PM, Colin Davis <[email protected] > > > <mailto:[email protected]>> wrote: > > > > > > I think Matthew's Proposal is a great idea- > > > I don't think that Freenet should do a general port proxy though, > > Alex. > > > > > > The big difference from a user-standpoint is that for HTTP, they > > can > > > just enter a URL into their browser, and it'll connect and pull over > > the > > > page. They don't need to set proxy information, or anything else. > > > That's DRAMATICALLY simpler for the user. > > > From an implementation standpoint, ICQ, IRC, etc require a > > constant > > > bitstream, which is more complex to engineer than individual http > > > requests. > > > > > > But a web-page request and forward would be very useful, immediately, > > > and gives people a good incentive to use Freenet. It's a > > gateway-drug, > > > and is useful both in increasing Freenet adoption and in increasing > > the > > > number of darknet connection. > > > > > > -Colin > > > > > > > > > Alex Pyattaev wrote: > > > > > > > > Heh, you'll never belive, but I have had the same idea a few days > > > > before when I was first installing freenet. And in fact, in order > > to > > > > help those trapped inside a firewall, a more convinient for those > > > > trapped solution could be found - a tunnel. A tunnel is much more > > > > flexible in terms of protocol - it allows to transmit IRc, ICQ, > > email > > > > ,HTTP or whatever else, and does not require any protocol > > > implementation. > > > > In fact, a primitive tunnel consists of a daemon which listens to > > a > > > > particular port and sends all packets to some other host inside > > > > freenet's internal encrypted datastream just as a simple file. > > > Outside > > > > the firewall the very same daemon unpacks the datastream and sends > > > > packets to IP layer of the host OS, which routes them > > appropriately. > > > > The only thing that needs to be done is faking the sender IP so > > that > > > > it matches the tunnel provider's external IP address. > > > > So, exact transportation process looks like this: > > > > Sender behind firewall: > > > > IPSRC: any > > > > IPDST: banned site's IP > > > > DPORT: tunnel's entrance port > > > > SPORT: any valid port > > > > All intermediate peers transmit the packet inside encrypted > > > > datastream, so they do not care much > > > > Packet when exiting tunnel(sent from the daemon on the exit side): > > > > IPSRC: external IP of the exit > > > > IPDST: unchanged > > > > DPORT: the port the tunnel was configured for > > > > SPORT: the port which tunnel provider's tunnel daemon listens on > > > > When the response packet gets to the tunnel provider's node, it > > > > automatically gets into the tunnel and is transmitted to the > > > > firewalled machine. > > > > The only issue is that the tunnel needs to be configured > > separately > > > > for each connection, which is not very convinient, but will work > > for > > > > any protocol, not just HTTP. > > > > PS: for such cases there are some existing tunneling programs, so > > the > > > > banned site might consider using them. Or, we could use them as a > > > > backend - e.g. SSH. It is cross-platform, fast, and provides good > > > > level of security. > > > > > > > > On Thu, Aug 6, 2009 at 7:33 PM, Evan Daniel <[email protected] > > > <mailto:[email protected]> > > > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > > > > > On Thu, Aug 6, 2009 at 8:09 AM, Matthew > > > > Toseland<[email protected] > > > <mailto:[email protected]> > > > > <mailto:[email protected] > > > <mailto:[email protected]>>> wrote: > > > > > I propose that as a darknet value-add, and as an additional > > > tool > > > > for those in hostile regimes who have friends on the outside, > > we > > > > implement a web-proxy-over-your-darknet-peers option. Your > > > Friends > > > > would announce whether they are willing to proxy for you, and > > you > > > > could choose which friends to use, or allow it to use all of > > them > > > > (assuming people on the inside don't offer). You could then > > > > configure your browser to use Freenet as a proxy. This would > > not > > > > provide any anonymity but it would get you past network > > obstacles > > > > and/or out of Bad Place and into Happy Place. It's not a long > > > term > > > > solution, but: > > > > > - We have expended considerable effort on making darknet > > > viable: > > > > IP detection, ARKs etc. > > > > > - It could take advantage of future transport plugins, but > > even > > > > before that, FNP 0.7 is quite hard to block. > > > > > - Many people are in this situation. > > > > > - It is easy to implement. HTTP is complex but cache-less > > > > proxies can be very simple. > > > > > - It could be combined with longer term measures (growing > > the > > > > internal darknet), and just work for as long as it works. Most > > > > likely it would be throttled rather than blocked outright to > > > start > > > > with, hopefully allowing for a smooth-ish migration of users > > to > > > > more robust mechanisms... > > > > > - We could allow recursive proxying to some depth - maybe > > > friend > > > > of a friend. This would provide a further incentive to grow > > the > > > > internal darknet, which is what we want. > > > > > - The classic problem with proxies is that they are rare so > > > > hundreds of people connect to them, and the government finds > > out > > > > and blocks them. This does not apply here. > > > > > > > > I like it. Darknet features are a very good thing. This > > > probably > > > > also needs some care wrt bandwidth management (related to 3334 > > -- > > > > similar considerations probably apply). > > > > > > > > However, as I mentioned on IRC, there are several things I > > think > > > > should be higher priority. Of course, I'm not the one > > > implementing > > > > any of this, but here's my opinion anyway ;) In no > > > particular order: > > > > > > > > - Documentation! Both the plugins api and making sure that > > > the FCP > > > > docs on the wiki are current and correct. > > > > - Bloom filter sharing. (Probably? I have no idea what the > > > relative > > > > work required is for these two.) > > > > - Freetalk and a blogging app of some sort (though these are > > > probably > > > > mostly for someone other than toad?). > > > > - A few specific bugs: 3295 (percent encoding is horribly, > > > > embarrassingly broken -- in at least 5 different ways), 2931 > > > (split > > > > blocks evenly between splitfile segments -- should help > > > dramatically > > > > with availability), fixing top block healing on splitfiles > > > (discussed > > > > in 3358). > > > > - Low-latency inserts flag as per 3338. (I know, most people > > > probably > > > > don't care all that much, but I'd really like to see whether > > > Freenet > > > > can hit near-real-time latencies for the messaging app I'm > > > working > > > > on.) > > > > > > > > Also, it's worth considering other ways to make darknet > > > connections > > > > more useful (in addition to this, whether before or after I > > > don't have > > > > a strong opinion on). Enabling direct transfer of large > > > files would > > > > be good (at a bare minimum, this shouldn't fail silently like > > > it does > > > > right now). Improving messaging would be good; I should be > > > able to > > > > see recently sent / received messages (including timestamps), > > > queue a > > > > message to be sent when a peer comes online, and tell whether > > a > > > > message I've sent arrived successfully. > > > > > > > > Evan Daniel
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
