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

[Karsten Loesing]

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]
>>>
>>> [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. :/

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