Let clients choose bridges (without listing all their IPs)
The way I see this can be done is similar to how https://haveibeenpwned.com/API/v3#PwnedPasswords works.
- BridgeDB lists hashes of all the available bridges, from which there is no way to figure out their addresses, therefore block them.
- The client randomly chooses (and possibly filters out some hashes prior) a couple of hashes (however many BridgeDB is willing to give).
- The client sends the selected bridge's hashes (or indices from the response) to BridgeDB.
- BridgeDB returns the unhashed bridges under these hashes.
- The client verifies that the returned relays have the hashes that it requested.
Advantages (compared to letting BridgeDB choose bridges):
- The client can filter out bridges that are blocked for them. As far as I know, BridgeDB already does the same, but the client may know better. For example, if there is a third-party list of blocked bridges. They can complement each other.
- Protection against BridgeDB going evil and only giving out compromised or blocked bridges while trying to look normal. However, I believe an evil actor can still set up a bunch of evil bridges on the same couple of machines they're in control of. But it still makes it harder.
Disadvantages:
- It is quicker for the censor to get bridges as they can request only the bridges whose address they do not yet know (even if they're not on the BridgeDB's blocked list yet).
In case you're worried about listing all the bridges' hashes being computationally expensive (10 000 hashes is 312.5 kB), we may ask the client to specify a smaller subset of hashes instead of listing all of them (by giving page number or the first couple of digits of the hash, like haveibeenpwned.com does). But I think it needs to be made sure that the subset is not too small so it's harder for an evil BridgeDB to just generate evil bridges that match this subset on the fly.
We could make this method and the current one co-exist.
Related:
Edited by WofWca