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)
On Fri, Aug 7, 2009 at 12:39 PM, VolodyA! V Anarhist < Volodya at whengendarmesleeps.org> 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 <colin at sq7.org > > <mailto:colin at sq7.org>> 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 <evanbd at gmail.com > > <mailto:evanbd at gmail.com> > > > <mailto:evanbd at gmail.com <mailto:evanbd at gmail.com>>> wrote: > > > > > > On Thu, Aug 6, 2009 at 8:09 AM, Matthew > > > Toseland<toad at amphibian.dyndns.org > > <mailto:toad at amphibian.dyndns.org> > > > <mailto:toad at amphibian.dyndns.org > > <mailto:toad at amphibian.dyndns.org>>> 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 > > > _______________________________________________ > > > Devl mailing list > > > Devl at freenetproject.org <mailto:Devl at freenetproject.org> > > <mailto:Devl at freenetproject.org <mailto:Devl at freenetproject.org>> > > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > Devl mailing list > > > Devl at freenetproject.org <mailto:Devl at freenetproject.org> > > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > > _______________________________________________ > > Devl mailing list > > Devl at freenetproject.org <mailto:Devl at freenetproject.org> > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Devl mailing list > > Devl at freenetproject.org > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > -- > http://freedom.libsyn.com/ Echo of Freedom, Radical Podcast > http://www.freedomporn.org/ Freedom Porn, anarchist and activist smut > > "None of us are free until all of us are free." ~ Mihail Bakunin > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090807/8e478212/attachment.html>
