On Wed, Apr 16, 2014 at 04:51:20PM +0100, Ximin Luo wrote:
> As a side point though, I realised another issue for flashproxy. At
> the moment, the PT client sets the facilitator (the controller) on the
> command line. This means we can't use Bridges that come from different
> facilitators. Meek see
On 16/04/14 16:24, Ximin Luo wrote:
> On 16/04/14 16:11, Ximin Luo wrote:
>> On 16/04/14 15:56, George Kadianakis wrote:
>>> Ximin Luo 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
>>>
On 16/04/14 15:56, George Kadianakis wrote:
> Ximin Luo writes:
>
>>
>>
>>
>> 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) (fingerprint)
On 16/04/14 16:11, Ximin Luo wrote:
> On 16/04/14 15:56, George Kadianakis wrote:
>> Ximin Luo 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 the bridge be
Ximin Luo writes:
> ## 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
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
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 not explicitly mention this viewpoint.
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 explic
## 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
