Pick, and deploy, a new bridge authority

We are losing Tonga at the end of August (legacy/trac#19690 (moved)). That means we should spin up a new bridge authority.

What are the criteria we should be considering, for the operator, location, etc of this bridge authority? To answer that, I think we should start by brainstorming all of the risks that we should consider.

So: what are we trusting the bridge authority for? Related, what does the bridge authority see? And what does an adversary watching the bridge authority see?

First, it sees the unscrubbed bridge data, i.e. the IP addresses, usage stats, fingerprints, etc of bridges. I think this is the same as what bridgedb sees, but more detailed than what onionoo serves. We rely on the bridge authority to have high security so bad people can't break in and steal the bridge addresses (that's number 7 on https://blog.torproject.org/blog/research-problems-ten-ways-discover-tor-bridges).

Second, the bridge authority does bridge reachability tests. So somebody who watches its network connection gets to learn bridge addresses too. (Bridges use Tor, and encrypted begindir connections, to publish their descriptors to the bridge authority, so you can't learn about them that way.) This part is probably a design flaw, in that it's a shame we have centralized the reachability testing; but we don't have a better design for that currently, so it remains an issue here. (This is number eight on the blog post above.)

Third, it used to be the case, in the original design, that the bridge authority needs to have really high reliability and bandwidth. That requirement was because users were expected to go back to the bridge authority quite frequently, to see if their bridges have changed location. The original idea was that users would get n bridges, and over time k of them would move locations or something, and so long as at least 1 of the n remained working, the Tor client could automatically discover the new bridge locations by fetching updated bridge descriptors from Tonga. But we basically stopped building the bridge design before we got that part working, so it isn't really an issue here.

Fourth (added based on Sebastian's comment below), we are relying on the bridge authority to have a consistent IP address for a very long time, since bridges upload their descriptors using this address. That is, I think it is the case that changing its IP address is effectively the same as picking a new bridge authority?

What other constraints/risks/goals did I miss?