Opened 3 years ago

Closed 15 months ago

#17094 closed defect (not a bug)

implicitly set 'UseBridges 1' when using 'Bridge [transport] IP:ORPort [fingerprint]'

Reported by: proper Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords:
Cc: whonix-devel@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Unless I am missing the reason for this...

When one is using a Bridge [transport] IP:ORPort [fingerprint] in their /etc/tor/torrc, then why is it required to also set UseBridges 1?

Couldn't Tor implicitly assume/set UseBridges 1 then? I suggest it should.

Child Tickets

Change History (15)

comment:1 Changed 3 years ago by nickm

Milestone: Tor: 0.2.8.x-final

comment:2 Changed 3 years ago by rl1987

I wouldn't be sure about this. What if user has UseBridges 0 in their torrc and some Bridge entries as well? In that case it is reasonably to assume they don't want to use bridges right now, but want to have them ready in case network censorship happens. The same probably holds if they have Bridge entries, but no UseBridges entry.

comment:3 Changed 3 years ago by proper

I assume, if users are using a Bridge line but forgot to set UseBridges 1, that they really want to use bridges right now. Just unaware forget about that option. Hence, I opened this ticket as a security/usability enhancement.

The case where users are using a Bridge line and set UseBridges 0 seems weird indeed. It's a contradiction. In that case, failing to start or not using the network seems reasonable to me.

comment:4 Changed 3 years ago by rl1987

Well the manpage spells out that you need to have UseBridges 1 line in your torrc if you want your Tor instance to use the bridges that are specified in Bridge entries. Therefore Bridge entries make Tor aware of certain bridges, but not tell Tor to use them per se.

comment:5 Changed 3 years ago by proper

Only a fraction of users reads man pages.

The purpose of the original suggestion in this ticket is to follow the principle of least surprise.

comment:6 Changed 3 years ago by nickm

Milestone: Tor: 0.2.8.x-finalTor: 0.2.???

Move a few tickets out of 0.2.8. I would take a good patch for most of these if somebody writes one. (If you do, please make the ticket needs_review and move it back into maint-0.2.8 milestone. :) )

comment:7 Changed 3 years ago by arma

Severity: Normal

I'm with rl1987 -- the reason I designed it this way is so you can have bridges in your torrc, but control whether to use them with the usebridges option.

(I seem to remember another ticket along exactly these lines, which I commented on some years ago. Perhaps it got closed as wont-fix, so it's harder to find?)

comment:8 Changed 3 years ago by teor

I agree, while it reduces usability to have to add bridge lines and UseBridges, when you want to turn bridges off temporarily, it's much easier to set UseBridges 0 than eradicate all the bridge lines.

comment:9 Changed 3 years ago by adrelanos

I think users using Bridge lines and forgetting about UseBridges 1 are a lot more important. Users who want to have Bridge lines in their torrc but not use them could still set explicitly set UseBridges 0. That does not speak against implicit UseBridges 1

Also turning off all the bridge lines temporarily gets a lot simpler once #1922 was implemented.

Turning off bridges - isn't this a minority use case of developers and alike? Either you need them or you don't?

comment:10 Changed 2 years ago by arma

I could imagine a "UseBridges auto" default, which is a tristate that sets it to 1 if there are some bridge lines, and to 0 if there are no bridge lines.

Aside from the "different people want different behavior" issue in the comments above, another challenge we would have in changing the default behavior is that current people expect current behavior. For example, Debian users want to be able to upgrade their Tor and have their torrc file continue doing what they expect.

So if we want to change this default, we will need a plausible path for mitigating this issue (perhaps like we did for the ExitRelay auto world in #10067).

comment:11 Changed 2 years ago by rl1987

It seems that UseBridges was an AUTOBOOL at some point historically, but later turned into BOOL. Changelog has the following entry for Tor 0.2.2.29:

  o Major bugfixes:
    - Revert the UseBridges option to its behavior before 0.2.2.28-beta.
      When we changed the default behavior to "use bridges if any
      are listed in the torrc", we surprised users who had bridges
      in their torrc files but who didn't actually want to use them.
      Partial resolution for bug 3354.

and the following entry for 0.2.2.28-beta:

    - If "UseBridges 1" is set and no bridges are configured, Tor will
      now refuse to build any circuits until some bridges are set.
      If "UseBridges auto" is set, Tor will use bridges if they are
      configured and we are not running as a server, but otherwise will
      make circuits as usual. The new default is "auto". Patch by anonym,
      so the Tails LiveCD can stop automatically revealing you as a Tor
      user on startup.

See 507c1257a4d9c629fefc2adbad8db73607749734 for a changeset that made it AUTOBOOL and 3b41551b61a604b555891ecc7cb6f8bbde65d128 for changeset that reverted it back.

It appears it was not a good idea after all.

comment:12 Changed 22 months ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:13 Changed 21 months ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:14 Changed 16 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:15 Changed 15 months ago by nickm

Resolution: not a bug
Status: newclosed

It appears it was not a good idea after all.

Closing as notabug for compatibility and usability reasons as discussed above.

Note: See TracTickets for help on using tickets.