[tor-dev] Building better pluggable transports (Google Summer of Code)

[Tariq Elahi]

On 2013-05-28 4:42 PM, adrelanos wrote:
> The more pluggable transports, the better.
> Maybe if there are enough transports, the other side just gives up.


My interest is piqued by this statement and similar sounding ones that I 
hear, and myself also think, when talking about censorship.
I suspect that if certain information leakage events (ILE) are important 
for the censor then I don't think giving up is an option, even if it 
means doing the hard(?) task of blocking all the pluggable transports. 
Of course this is all conjecture---I don't know the censor---which 
brings me to my main point:

It is important that we have a model of which censor we are wanting to 
defeat (or at least annoy). I don't mean every censor or every use case, 
just the one we are currently discussing. Also, we can have different 
descriptions of the same censor depending on the situation. The same 
censor can bring to bear very different tools depending on if the users 
are being annoying enough, or if ultimately the problem can be dealt 
with by non-Internet means. This also allows us to talk about the same 
censor and produce different censorship solutions depending on our goals 
and the censorship conditions that apply. We can through our actions 
(like becoming popular) shift the censorship context and thus have to 
reevaluate our solution.

I know that it is fiendishly difficult to get correct but it would help 
the discussion if we knew exactly what we're up against, at least in 
qualitative terms.

My attempt from what I think we're talking about, please correct/add to 
this where I err:

Circumvention strategies:
0. Collateral damage and obfuscation.

Censor Capabilities:
1. View all traffic coming in and out of a network (most likely has 
visibility of all AS and IX level traffic). We'll call this the 
visibility bubble.
2. Can manipulate (add, delete, change) said traffic in time and data 
dimensions.

Motivations:
3. Block *all* information leakage events. This means if even one ILE 
occurs the circumventor wins.
4. Limit collateral damage but some is acceptable.

Censorship Target:
5. General user population (G) within the visibility of the bubble.
6. Circumventor population (Cr) in visibility bubble.
7. Cr/G << 1; the incidence rate (R).

I think that this censor, while in a seemingly powerful position due to 
1 and 2, is in a difficult dilemma due to 3 and 4, especially if 7 is a 
small number.
Of course if we relax the condition of blocking *all* ILEs then the 
situation becomes more favorable for the censor.

I hope that descriptions such as the above really help identify the 
issues at hand helps focus on what is pertinent. I suspect that with Tor 
being useful to a diverse user-base the censorship scenarios are just as 
varied and the solutions (even within the plugabble transport space) can 
be useful in ways we did not think of.

Cheers,
-mtee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20130528/5a99074a/attachment-0001.html>