On Mon, Dec 3, 2012 at 10:19 PM, Mike Perry wrote:
> Thus spake George Kadianakis (desnac...@riseup.net):
>
>> Hi,
>>
>> - Started researching and developing obfs3, an improved version of the
>> obfs2 pluggable transport. The proposed protocol currently looks
>> like this:
>>
>> https://git
Thus spake George Kadianakis (desnac...@riseup.net):
> Hi,
>
> - Started researching and developing obfs3, an improved version of the
> obfs2 pluggable transport. The proposed protocol currently looks
> like this:
>
> https://gitweb.torproject.org/user/asn/pyobfsproxy.git/blob/refs/heads/o
David Fifield:
> The next step is
> https://trac.torproject.org/projects/tor/ticket/7621, which is
> about installing these programs into a Tor Browser Bundle. Perhaps
> we should try to coordinate this into a combined pyobfsproxy/flash
> proxy bundle?
There is no need for one bundle with obfsprox
I noticed a change in behavior in cb62a0b69a7d67b427224ca4c3075b49853a3a1f
or thereabouts. tor opens a new SOCKS connection to a client transport
plugin while bootstrapping at 50% (if descriptors are not cached) or at
85% (if descriptors are not cached). The upshot is that the flash proxy
transport