[tor-bugs] #24456 [Core Tor/Tor]: Figure out what to do with the guardfraction feature

[Tor Bug Tracker & Wiki]

#24456: Figure out what to do with the guardfraction feature
-------------------------------------------------+-------------------------
 Reporter:  asn                                  |          Owner:  (none)
     Type:  defect                               |         Status:
                                                 |  needs_review
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.3.3.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-dirauth, tor-guard, review-      |  Actual Points:
  group-32, review-group-33                      |
Parent ID:                                       |         Points:  2
 Reviewer:  mikeperry                            |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by mikeperry):

 Replying to [comment:19 asn]:
 > I can see some ways forward here:
 >
 > a) We go ahead with the plan of comment:6 (and my branch) to kill this
 feature completely, in the assumption that we lack the time and power to
 fix and support it in the medium-term future. If in 3-4 years we decide to
 restart this project we would have to merge the code in again, add more
 consensus methods, etc.
 > b) We keep the code in (and maybe obsolete the torrc options) and ask
 all dirauths to stop running the python script until further notice. This
 would be done in the assumption that we would be able to revive this
 project in the future. That said, I think currently the fire department is
 well out of vehicles to even think of reviving this project, let alone
 start doing it.
 >
 > Is there a different approach we could take? What should we do?

 I don't see any clear reason to actually remove the code. As I see it, the
 following are all true:
 1. #16255 stalled because we lacked an easy-to-use testing mechanism to
 test consensus changes. The fix looks otherwise correct to me. I agree
 that it is a PITA to test. But as soon as we can test it, it is likely to
 work.
 2. We are likely to build consensus-testing code at some point, regardless
 of this feature. It may be useful for vanguards tests. It will be useful
 for load balancing changes for padding (#8453)
 3. We do want guardfraction eventually.
 4. Future guardfraction implementations will very likely still be an
 external script+input file because the long-term statekeeping involved is
 much easier externally.
 5. The tor-core code for the guardfraction system is isolated and is not
 adding complexity while disabled.
 6. If we deprecate/disable the torrc options, dirauths will turn it off,
 perhaps automatically, on the same timescale as if we actually removed the
 code.

 To me, this all points towards obsoleting the torrc options (perhaps in a
 way that causes them to stop the files from being read even if they are
 still set), but not removing the code.

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