[tor-dev] Building better pluggable transports (Google Summer of Code)
tariq.elahi at uwaterloo.ca
Tue May 28 23:55:45 UTC 2013
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
My attempt from what I think we're talking about, please correct/add to
this where I err:
0. Collateral damage and obfuscation.
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
2. Can manipulate (add, delete, change) said traffic in time and data
3. Block *all* information leakage events. This means if even one ILE
occurs the circumventor wins.
4. Limit collateral damage but some is acceptable.
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tor-dev