[tor-dev] Why the seeming anticorrelation between obfs3 and vanilla bridges in metrics graphs?

David Fifield david at bamsoftware.com
Sun Oct 26 00:21:35 UTC 2014

On Thu, Oct 23, 2014 at 10:32:41AM -0700, David Fifield wrote:
> In the past few months of bridge user graphs, there is an apparent
> negative correlation between obfs3 users and vanilla users: when one
> goes up, the other goes down. If you draw a horizontal line at about
> 5500, they are almost mirror images of each other. I don't see it with
> any other transport pairs. Any idea why it might be?
> I can see what could cause a simultaneous decrease in vanilla and
> increase in obfs3: Tor gets blocked somewhere and users switch to obfs3.
> But I wouldn't expect blocking events to look so smooth or happen so
> frequently, and it doesn't explain why the reverse change happens later
> (obfs3 being blocked while Tor is unblocked is less plausible). I can
> also understand the overall long-term trend of obfs3 increasing and
> vanilla decreasing. But I don't see why they should mirror each other so
> closely over short time periods.
> Some hypotheses:
>  1. There are lots of users who have a mix of vanilla and obfs3 bridges
>     configured. Their tor (randomly?) chooses one of them, which usually
>     works. The number of such users is constant over the short term;
>     i.e. the sum of obfs3+vanilla is constant, but the proportion of
>     obfs3 and vanilla fluctuates randomly.
>  2. Maybe vanilla-down/obfs3-up is caused by blocking events, and
>     vanilla-up/obfs3-down is caused by natural new-user churn and/or
>     coincidence.
>  3. There is something about the way BridgeDB hands out bridges, or the
>     way in which users use it, that causes it to give out obfs3 bridges
>     at the expense of vanilla and vice versa.
>  4. Some kind of feedback loop: obfs3 bridges get used and get
>     congested, so users switch to vanilla, which then get used and
>     congested, etc.

I meant to include a link to the source graph (where you can also
experiment with adding other transports).


David Fifield

More information about the tor-dev mailing list