In response to overwhelming criticism over the centralized nature and vulnerability of the bridge authority server and possible (read: pretty much 100% certain) exploitation by national governments, especially the USA, of this centralized infrastructure.
The USA doesn't block bridges, so how are they exploiting it? If you want to thwart traffic analysis by your government, use bridges/relays outside of your country to maximize jurisdictional barriers. Actually, the probability of all 3 of the relays in a circuit residing inside your jurisdiction is very small already. Tor relays are spread across 75 countries, so there's little the US or Chinese governments can do to correlate traffic, unless they get really lucky (yes, there are some sophisticated fingerprinting attacks but none have been discovered in the wild).
Bridge enumeration is mainly a problem in China and other places that actively block connections to the Tor network.
The new concept of a Bridge Community changes all of that.
You run your own bridge authority, and possibly a pool of bridge relays, then publish the IP:port pairs to that bridge authority. Your community members can then use a few IP:port pairs you give them directly to connect to the bridge community. These bridges then relay all traffic for that community into the wider public relay pool.
The is an interesting idea, and I'd like to see how it works in practice.
However, it seems to introduce a new problem: the bridge authority operator is linked to the users. I mean, how do they find out about the bridge authority besides some kind of prior knowledge of the operator? On the other hand, if anyone can find out about a bridge pool, what is to stop censorship regimes from finding out about it?
It's similar to the problem that plagues exit guards, which haven't been implemented.
To keep up with the inevitable arms race that will ensue when obfusproxy becomes more common among normal tor users, obfusproxy version 3 uses "pluggable transports" where you can easily design a new module for exploiting unintended features in underlying cover protocols.
Yeah, I can't wait for this to be standard.