Re: [tor-dev] Flashproxy alpha bundles

2012-12-14 Thread David Fifield
On Thu, Dec 13, 2012 at 05:10:52PM +, adrelanos wrote: > Or wait for IPv6 and such problems will vanish? In fact IPv6 is one solution to the NAT problem. To my surprise, there are a few IPv6 flash proxies operating. I was able to bootstrap and surf over a couple of them, using an he.net tunnel

Re: [tor-dev] Flashproxy alpha bundles

2012-12-14 Thread Alexandre
Thanks for pointing this out. I always run the programs from a console, in which case there is no extra pop-up console, so I hadn't noticed the issue. We should be able to get rid of them in future releases. Alex On 2012-12-14, at 10:34 AM, "Sebastian G. " wrote: > Alexandre: >> The "scary

Re: [tor-dev] Flashproxy alpha bundles

2012-12-14 Thread Sebastian G.
Alexandre: > The "scary console" mentioned in the test report is probably > because of the console=true option in the pyinstaller > spec file. I'll have a look and confirm. > > Alex > My report might be misleading. When I execute "tor-flashproxy-browser-2.4.6-alpha-2_en-US.exe" a console window

Re: [tor-dev] Flashproxy alpha bundles

2012-12-14 Thread Alexandre
Nice. Im hoping things like browser games will make APIs like that widely implemented. Alex On 2012-12-14, at 7:52 AM, Veggie Monster wrote: >> connections, so browser implementations don't let you do it. >> So the user has to be able to accept connections on his end. > > Apparently Chrome Ca

Re: [tor-dev] Flashproxy alpha bundles

2012-12-14 Thread Veggie Monster
> connections, so browser implementations don't let you do it. > So the user has to be able to accept connections on his end. Apparently Chrome Canary lets you do that: http://iceddev.github.com/blog/2012/11/05/node-js-in-chrome/ Vmon ___ tor-dev mail

Re: [tor-dev] Flashproxy alpha bundles

2012-12-13 Thread Alexandre
The "scary console" mentioned in the test report is probably because of the console=true option in the pyinstaller spec file. I'll have a look and confirm. Alex On 2012-12-13, at 7:01 PM, David Fifield wrote: > Thank you for testing! This report is very helpful. > > On Thu, Dec 13, 2012 at 07:

Re: [tor-dev] Flashproxy alpha bundles

2012-12-13 Thread David Fifield
Thank you for testing! This report is very helpful. On Thu, Dec 13, 2012 at 07:59:31PM +0100, Sebastian G. wrote: > > - If it didn't work, was it at least clear what was wrong? > > I thought the progress would have stopped here, but it just took much > longer than expected. > > [Notice] Bootstr

Re: [tor-dev] Flashproxy alpha bundles

2012-12-13 Thread adrelanos
Roger Dingledine: > Whether these various "look, no hands" punching tools and tricks can be > done using only websockets on the remote side is a great question for > somebody to answer. By the way, I found it in their design paper. Quote: The fact that clients must not be behind NAT is an impedi

Re: [tor-dev] Flashproxy alpha bundles

2012-12-13 Thread adrelanos
Alexandre: > You can get the full details on flash proxies here: > > https://crypto.stanford.edu/flashproxy/ I read the full paper. It's amazing. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo

Re: [tor-dev] Flashproxy alpha bundles

2012-12-13 Thread adrelanos
Roger Dingledine: > On Thu, Dec 13, 2012 at 06:38:03PM +, adrelanos wrote: >> Have you considered Hole punching techniques? [1] TCP, UDP, ICMP hole >> punching... There are many techniques. I don't know if the WebSocket >> protocol would prevent it. >> >> STUN [2] like techniques where a third

Re: [tor-dev] Flashproxy alpha bundles

2012-12-13 Thread Roger Dingledine
On Thu, Dec 13, 2012 at 06:38:03PM +, adrelanos wrote: > Have you considered Hole punching techniques? [1] TCP, UDP, ICMP hole > punching... There are many techniques. I don't know if the WebSocket > protocol would prevent it. > > STUN [2] like techniques where a third non-firewalled server he

Re: [tor-dev] Flashproxy alpha bundles

2012-12-13 Thread Sebastian G.
Alexandre: > Windows: > https://people.torproject.org/~dcf/flashproxy/tor-flashproxy-browser-2.4.6-alpha-2_en-US.exe > https://people.torproject.org/~dcf/flashproxy/tor-flashproxy-browser-2.4.6-alpha-2_en-US.exe.asc Thanks my platform. (Windows 7 64bit) > Some specific things we would like feedb

Re: [tor-dev] Flashproxy alpha bundles

2012-12-13 Thread adrelanos
Have you considered Hole punching techniques? [1] TCP, UDP, ICMP hole punching... There are many techniques. I don't know if the WebSocket protocol would prevent it. STUN [2] like techniques where a third non-firewalled server helps to traversal the NAT. (Only NAT, not used a proxy.) pwnat [3] al

Re: [tor-dev] Flashproxy alpha bundles

2012-12-13 Thread Alexandre
It's unfortunately a limitation of the technology we are using. The proxies run as javascript code in peoples' web browsers, and use the WebSocket protocol to relay traffic from the client to the relay. This protocol is designed to allow bidirectional communication from a browser to a web server

Re: [tor-dev] Flashproxy alpha bundles

2012-12-13 Thread adrelanos
Alexandre: > - Is configuring port forwarding insurmountable for you? It was always too much to ask the user to set up a port forwarding. Try asking your non-technical friends or family. You'll see. Alternatively search for RetroShare, emule, filesharing port forwarding and see how many people hav

[tor-dev] Flashproxy alpha bundles

2012-12-13 Thread Alexandre
Hello everybody, We now have some flashproxy Tor Browser Bundles ready. These are alpha bundles, made by adding our files to the existing obfsproxy bundle. We would appreciate some testing and feedback. You can get the bundles here: Windows: https://people.torproject.org/~dcf/flashproxy/tor-flash