[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



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
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev