On Thursday 06 August 2009 23:00:14 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).
Not if ssh is blocked. > And those who can not set up a > tunnel via ssh, probably will be happy with zero-configuration proxy for web > access. Not if that is blocked too! And yes, both are true in some places (notably Iran). > 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. The proposal is that it would not be anonymous at all, at least initially. > > On Thu, Aug 6, 2009 at 9:48 PM, Colin Davis <[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]>> wrote: > > > > > > On Thu, Aug 6, 2009 at 8:09 AM, Matthew > > > Toseland<[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 > > > _______________________________________________ > > > Devl mailing list > > > [email protected] <mailto:[email protected]> > > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > Devl mailing list > > > [email protected] > > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > > _______________________________________________ > > Devl mailing list > > [email protected] > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > >
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
