On 16/10/14 10:57, isis wrote:
Karsten Loesing transcribed 1.9K bytes:
On 16/10/14 09:06, isis wrote:
Roger Dingledine transcribed 1.0K bytes:
Your best bet at a short-term hack might be to add a line to the descriptor which politely asks bridgedb not to give its address out.
Interesting idea...
Would this help Metrics produce more accurate data for the bridges which are built into Tor Browsers (but absent from BridgeDB)?
Yes, it would.
Great! All the more reason to do it.
The alternative would be to remove all bridges from the bundles which don't publish their descriptors to Tonga/BridgeDB.
That sounds like more maintenance for the Tor Browser Team, only to punish bridge operators who don't give metrics. This sounds less than ideal.
The address is already in the public bundle, so what's the purpose of hiding it from BridgeDB... I talked to bridge operators a couple times but did not succeed and then gave up.
Strange...
Well, nothing would change for those bridge operators if we implemented this option, since they'd still presumedly continue on with `PublishServerDescriptor 0` in their configs, unless, like David, they would be particularly interested in producing metrics and using the new option.
<rant>
Actually, the guideline should be to only add public bridges to the public bundles. If a bridge operator offers a bridge for the bundle, check that it publishes descriptors, and if not, don't add it. And if any of the current bridges doesn't publish descriptors, remove it from the bundles now. I don't see how this adds more maintenance to anyone.
Having private bridges in public bundles is actually harmful, because it makes it look like bridges are not much used. If we want to suggest bridge development or BridgeDB development to a sponsor and they look at estimated user numbers compared to directly connecting users, they might say that those few users are not worth their money.
But as I said before, meh.
</rant>
Is there another use case?
Private bridges which are set up by people to help their friends and family would also be included in the statistics.
Hmm. I wonder if a private bridge sending in its descriptor at regular intervals is enough of a distiguisher to differentiate it from actually being a Tor client.
Possibly.
Also, with that setting, we could consider doing something like #4026, [0] except have the info specified in the descriptor. Something like:
BridgeDistribution [email]|[https]|[none]|[any]
Good idea. I'm inclined to put that field into Onionoo for Atlas and Globe to display it. Then you and Matt can stop providing bridge pool assignment files and I can stop processing them in metrics-db/Onionoo. One thing less to maintain. We can always resume sanitizing BridgeDB data when you and Matt came up with some good statistics.
That would be excellent. :D
Though, as much as I would absolutely love for none of us to have to deal with BridgeDB assignment files, I suspect this wouldn't quite let us do that. At least, not without losing some visibility into the pool sizes: If a bridge were to choose `BridgeDistribution any`, BridgeDB would assign it, and then (without the assignments file) Metrics wouldn't have any idea which distribution method it was assigned to. If we don't mind Metrics having fuzzy data on the bridge pool sizes, then perhaps this is okay. Otherwise, BridgeDB would have to continue dumping those pools. :/
I'm fine with this inaccuracy. The only thing that uses bridge pool assignments is Onionoo/Atlas/Globe, and providing the information which pool/ring BridgeDB picked for a bridge doesn't justify the effort.
Another thing to consider: should we allow a bridge operator to switch from `BridgeDistribution https` to `BridgeDistribution email`? Allowing this would, of course, decrease our potential to understand how bridges are being harvested/blocked, as well as nullifying some of the security considerations which influenced the separate-hashrings-for-separate-distribution-methods design choice.
I'd say it's up to the bridge operator to decide how their bridge is used, even if that makes it easier to enumerate/block their bridge. Worth a comment in torrc, but no reason to ignore their choice.
All the best, Karsten