[tor-dev] Is PublishServerDescriptor needed to collect metrics?

[isis]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1154 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20141016/9a7df28b/attachment.sig>