Is PublishServerDescriptor needed to collect metrics?
If a bridge has PublishServerDescriptor 0 does that prevent it from counting in metrics? If so, what's the right setting to enable metrics (0|1|v3|bridge,...)? Is there a way to send metrics data without also ending up in BridgeDB? David Fifield
On Mon, Oct 13, 2014 at 09:44:24PM -0700, David Fifield wrote:
If a bridge has PublishServerDescriptor 0 does that prevent it from counting in metrics?
Correct. If it's set to 0, it never goes to the bridge authority, so none of the metrics databases ever see it.
If so, what's the right setting to enable metrics (0|1|v3|bridge,...)?
The man page says: The default is "1", which means "if running as a server, publish the appropriate descriptors to the authorities". So if you leave it at "1", it will know that you meant "bridge".
Is there a way to send metrics data without also ending up in BridgeDB?
Alas, not currently. That's because the metrics data is a side effect of the bridge authority / bridgedb data flow. 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. --Roger
Roger Dingledine transcribed 1.0K bytes:
On Mon, Oct 13, 2014 at 09:44:24PM -0700, David Fifield wrote:
Is there a way to send metrics data without also ending up in BridgeDB?
Alas, not currently. That's because the metrics data is a side effect of the bridge authority / bridgedb data flow.
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)? Is there another use case? 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 -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt
On 16/10/14 09:06, isis wrote:
Roger Dingledine transcribed 1.0K bytes:
On Mon, Oct 13, 2014 at 09:44:24PM -0700, David Fifield wrote:
Is there a way to send metrics data without also ending up in BridgeDB?
Alas, not currently. That's because the metrics data is a side effect of the bridge authority / bridgedb data flow.
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. The alternative would be to remove all bridges from the bundles which don't publish their descriptors to Tonga/BridgeDB. 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.
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. Maybe there are more use cases.
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. All the best, Karsten
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]
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
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
Karsten Loesing transcribed 4.5K bytes:
On 16/10/14 10:57, isis wrote:
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.
Okay, you got me ― I'm totally on your side now. :) Dear Tor Browser Team, I am willing to curate your bundled bridges for you to ensure that they are public bridges.
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.
Hooray! Less work!
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.
Fair enough. And, now that I think about it more, the default should probably be `BridgeDistribution any` to maintain consistent behaviour, meaning that bridge operators would have some chance of altering their assignment anyway if they manual set the option later. -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16/10/14 11:56, isis wrote:
Karsten Loesing transcribed 4.5K bytes:
On 16/10/14 10:57, isis wrote:
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.
Okay, you got me ― I'm totally on your side now. :)
Dear Tor Browser Team, I am willing to curate your bundled bridges for you to ensure that they are public bridges.
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.
Hooray! Less work!
FWIW, I'm moving forward here by removing bridge pool assignment information from Onionoo/Atlas/Globe and replacing that field with transport names. See #11052 for details. I hope to get this deployed this week. The next step will be to stop collecting/sanitizing bridge assignment files from BridgeDB in CollecTor. I'm planning to make that change next week.
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.
Fair enough. And, now that I think about it more, the default should probably be `BridgeDistribution any` to maintain consistent behaviour, meaning that bridge operators would have some chance of altering their assignment anyway if they manual set the option later.
Once there's a BridgeDistribution config option and corresponding line in server/extra-info descriptors, I'm happy to include that in Onionoo/Atlas/Globe. The same goes for more serious usage statistics provided by BridgeDB than the old assignment-file hack that I helped put in long ago. All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJUfdkFAAoJEJd5OEYhk8hI75wIAKWhHU/XioWR7Mgr9wJU9ogU cg2PHVRz1fyuR6LubAAJq90aepJ2YCUsX/T1nl40eMDxq3iTUgz1upsHPAq8ribo Imy2PPZLltRNuQI2CjQvh9Gjv+vCJYlJvFivs/l2Def9SDRon2Nj7PxP+tmxN6AC YplXsvb+3Gh/JlQqfxm61gsilWzV60fPM/px7WgweMDvO9b/TGdBKUF6cP2LxY+w IVbvyfUqqrooOSUt0gc2DUHAnmoNQyh7NdDxBLUmZxoyndl5CvkAPWUj0o1sCrsK LocOT8ZePSeh7OxdPvuMPVmo+6NsadqGc1Usv7m0pYkbUNYsFG+vhqTjk+zBwqk= =sxal -----END PGP SIGNATURE-----
participants (4)
-
David Fifield -
isis -
Karsten Loesing -
Roger Dingledine