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. > > 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. > > 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] > > > > [0]: https://trac.torproject.org/projects/tor/ticket/4026 > > 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. :/ 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. -- ââ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev