Opened 6 years ago

Last modified 2 years ago

#9208 needs_information enhancement

Allow node operator to avoid Guard flag

Reported by: cypherpunks Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: guard tor-relay needs-proposal
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


For various reasons node operator may wish to not become guard node. Add cfg option for publishing such wish to directory server.

Child Tickets

Change History (8)

comment:1 Changed 6 years ago by nickm

Keywords: tor-relay needs-proposal added
Milestone: Tor: unspecified
Status: newneeds_information

What kind of reasons are these? This wouldn't be very hard if there are indeed important reasons to do this. It would require a proposal, and that's about all. (The easiest way to implement it would be a new descriptor element combined with updated authority behavior.)

comment:2 Changed 6 years ago by cypherpunks

  1. Suspection that network is scanned for tor clients in country with censored internet.
  1. suspection that machine admin harvests ip adresses of tor clients for its web forum blacklist. tor runs from regular user account.
  1. lower number of open connections to keep resource usage down

comment:3 Changed 6 years ago by hsn

turn off relay for half day. its enough to loose guard and stable flag.

comment:4 Changed 6 years ago by hsn

proposed on IRC BadGuard flag has one more advantage. Exit nodes can use it for better efectivity - they will never become guards and have more bandwidth available for exiting tor traffic.

comment:6 Changed 5 years ago by hsn

why BadGuard flag will be helpful:


In one of networks hosting my relays any tcp connection made is logged and retained for 6 months because its required by local law.

Adding somewhat operator controllable badguard flag will allow me to make sure that nobody is getting into trouble for using tor. Countries punishing people for using tor might know that in certain regions all connections are logged because of their local laws and request IP addresses of ppl connecting to particular relay.


Current tor network is limited by exit node bandwidth. All configured exit node bw capacity is getting used, while this is not case for guard or middle nodes - they sits on unused bw because its not needed. Exit node with badguard flag or without guard flag would be more efficient because larger portion of its bandwidth would be used for exiting instead of relaying traffic. Only 1/4 of all current tor relays are exits, 3/4 are enough for doing guarding/relaying.

comment:7 Changed 2 years ago by nickm

Severity: Normal

comment:8 in reply to:  6 Changed 2 years ago by arma

Reason (2) is not actually an issue, since our current consensus weighting algorithms have clients avoid using guardexits as guards, since they know everybody else will already be using them as exits.

Reason (1) has some merit to it though. I would be kind of sad to give up on that, since some folks might opt out of being a guard when otherwise they wouldn't, and diversity of guards is really important to Tor's security. But maybe we should do it anyway, on the theory that Tor is about giving people choice, and taking away some choices from relays works against that principle.

Note: See TracTickets for help on using tickets.