On Thursday 06 August 2009 23:58:15 Colin Davis wrote: > That's a fair point, but I'm not sure how likely it would be that ssh > is blocked and freenet isn't.
From what I hear this is true right now in Iran. > Once there are more hidden transports, > perhaps, but as it is, running ssh on an alternative port or using nc > to tunnel over https seems more resilant than Freenet. > > On the other hand, your the one who would be implementing it, so you > would know the relative difficulty better than I. > > I still contend that building the web proxy component into fproxy > would be good UI. It drives people to the Freenet interface, and it's > clearer than setting proxy information, if you've never done it. So you're in favour, greaat. > > > Sent from my iPhone > > On Aug 6, 2009, at 6:30 PM, Matthew Toseland > <[email protected]> wrote: > > > 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 > >>> > >> > > > > > > _______________________________________________ > > 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
