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
