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

changed milestone to %Tor: unspecified

added component::core tor/tor milestone::Tor: unspecified priority::medium resolution::not a bug severity::normal status::closed type::defect labels

Trac:
Milestone: N/A to Tor: 0.2.8.x-final

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.

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.

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.

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.

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. :) )

Trac:
Milestone: Tor: 0.2.8.x-final to Tor: 0.2.???

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?)

Trac:
Sponsor: N/A to N/A
Severity: N/A to Normal

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.

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 (moved) was implemented.

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

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 (moved)).

Trac:
Reviewer: N/A to N/A

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.

Milestone renamed

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.3.???

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

Trac:
Keywords: N/A deleted, tor-03-unspecified-201612 added
Milestone: Tor: 0.3.??? to Tor: unspecified

Remove an old triaging keyword.

Trac:
Keywords: tor-03-unspecified-201612 deleted, N/A added

It appears it was not a good idea after all.

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

Trac:
Status: new to closed
Resolution: N/A to not a bug

closed

moved to tpo/core/tor#17094 (closed)

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

Child items 0

Activity