[metrics-bugs] #33008 [Metrics/Relay Search]: Display a bridge's distribution bucket

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon Mar 16 18:21:04 UTC 2020

#33008: Display a bridge's distribution bucket
 Reporter:  phw                                  |          Owner:
                                                 |  metrics-team
     Type:  enhancement                          |         Status:
                                                 |  needs_review
 Priority:  Medium                               |      Milestone:
Component:  Metrics/Relay Search                 |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  s30-o24a1, anti-censorship-roadmap-  |  Actual Points:
  2020Q1 metrics-team-roadmap-2020Q1             |
Parent ID:  #31281                               |         Points:  2
 Reviewer:  cohosh                               |        Sponsor:
                                                 |  Sponsor30-can

Comment (by phw):

 Replying to [comment:23 karsten]:
 > Okay, I agree that we should distinguish five bridge distribution
 mechanisms in Relay Search with links to BridgeDB's information page:
 >  - "HTTPS", "Email", and "Moat";
 >  - "Reserved": also known as "unallocated" in bridge pool assignment
 files which most bridge operators will never hear about; and
 >  - "None": either not distributed by BridgeDB as requested by the bridge
 operator, or distributed via one of the four other mechanisms but too new
 for Relay Search to know. (The info page should probably mention both
 > If this makes sense, we can tell Relay Search to display these terms
 (using this capitalization) rather than the raw strings it receives from
 bridge pool assignment files.
 Yes, this sounds good to me. BridgeDB's new info page will have anchors
 for all (https, moat, email, reserved, none), for example:
 bridges.torproject.org/info#https. Does this work for you?
 > Regarding a possible change to BridgeDB to actually rename these strings
 in bridge pool assignment files, I'd rather want to avoid that. There's
 not really a spec for bridge pool assignment files where we could write
 down when we changed "unallocated" to "reserved" and why. Soon we'd forgot
 why we renamed this string and whether "unallocated" and "reserved" are
 actually the same thing or not. It's a bit like onion service directories
 still using relay flag "HSDir" rather than "OSDir". Historically,
 "unallocated" was the correct term when the only alternatives were to
 allocate a bridge to the HTTPS or Email distributor. It's just a bit less
 correct since there's now another alternative to really not assign a
 bridge to any distributor and instead drop it.
 Ok, then I would suggest calling it "Reserved" on both Relay Search and on
 BridgeDB's info page but leaving it as "unallocated" in the bridge pool
 assignment. I'll explain this discrepancy on the info page to minimise

Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33008#comment:24>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

More information about the metrics-bugs mailing list