On 16/04/14 15:56, George Kadianakis wrote:
Ximin Luo infini...@torproject.org writes:
snip
So instead of having, as currently:
(old, hacky) Bridge flashproxy (dummy addr)
We would have the following cases:
(1) Bridge flashproxy (real addr)
(2) Bridge flashproxy (real addr)
On 16/04/14 16:11, Ximin Luo wrote:
On 16/04/14 15:56, George Kadianakis wrote:
Ximin Luo infini...@torproject.org writes:
Hm, but this kind of kills the magic of indirect PTs, right? That is,
users who want to use flashproxy in the way above, will have to know
an address or a fingerprint of
## Background
Pluggable Transports are proxy programs that help users bypass censorship.
[App client] - XXX EVIL CENSOR HAS YOU XXX ACCESS DENIED XXX
[App client] - [PT client] - (the cloud!) - [PT server] - [App server]
The structural design, on the client side, is roughly:
1. App client
On 15/04/14 14:03, Ximin Luo wrote:
(3, not-ideal) Bridge flashproxy (dummy addr) (fingerprint)
Option (3) is quite nice, since in indirect PTs the actual address is
irrelevant - the Tor client never tries to connect to it. I suggest that we
have a special syntax for it though, to explicitly
On 15/04/14 19:36, David Fifield wrote:
On Tue, Apr 15, 2014 at 02:03:43PM +0100, Ximin Luo wrote:
## The problem
The problem with the above structure, is that it is incompatible with the
metaphor of connecting to a specific endpoint. This is what the PT spec is
about, even though it does
