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

Reply via email to