[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #2866 [Metrics]: Analyze bridges in the "reserved" bucket
#2866: Analyze bridges in the "reserved" bucket
---------------------+------------------------------------------------------
Reporter: karsten | Owner: karsten
Type: task | Status: new
Priority: normal | Milestone:
Component: Metrics | Version:
Keywords: | Parent:
Points: | Actualpoints:
---------------------+------------------------------------------------------
I'm interested in learning whether keeping a certain fraction of bridges
unassigned, that is not distributing them via email or HTTP, is a good
idea. AIUI, the idea was to have a small set of fresh bridges in case we
come up with a new distribution channel or want to give out fresh bridges
manually. This idea might fail if people who run a bridge that ends up in
the unallocated pool decide that their bridge is not being useful. They
might turn off their bridge or delete their keys in order to get a new
fingerprint and end up in another pool. If many people do so, we might
better allocate all bridges to pools directly and start a new pool
whenever there's a new distribution channel. Given the high churn of
bridges, we might have a sufficient set of fresh bridges in that pool very
soon. Also, if we want to give out bridges manually, we might give out
bridges from the other pools which may have higher uptime than bridges in
the unallocated pool. Allocating all bridges also means we don't have to
explain to bridge operators why their bridge is also useful even if it
doesn't have any users right now.
(This description comes from #2372 where we started with the same
question, but then focused on making the pool assignments publicly
available. Now that we have the assignments we can focus on this question
again.)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2866>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs