That's a fair point, but I'm not sure how likely it would be that ssh is blocked and freenet isn't. 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. Sent from my iPhone On Aug 6, 2009, at 6:30 PM, Matthew Toseland <toad at amphibian.dyndns.org> 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 <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>> wrote: >>>> >>>> On Thu, Aug 6, 2009 at 8:09 AM, Matthew >>>> Toseland<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> >>>> 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 >>> >>> _______________________________________________ >>> Devl mailing list >>> 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
