Opened 20 months ago

Last modified 6 months ago

#25713 new defect

"DisableNetwork is set" log message in Tor Browser scares/confuses users

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: ux-team, 040-deferred-20190220, ex-sponsor-19, ex-sponsor19
Cc: antonela, brade, mcs, catalyst Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

When Tor Browser has trouble connecting, we tell users to go look at the logs. The first thing they see in their logs is something like

 13/06/2017 11:31:29.600 [NOTICE] DisableNetwork is set. Tor will not make      
 or accept non-control network connections. Shutting down all existing          
 connections.

and if they're hunting for a log message that gives them a hint about why Tor doesn't work, that one is easy to find and seems really related to why their tor might not work.

So we have this recurring event where users come to us and say "My Tor Browser isn't working, it says DisableNetwork is set."

Now, Tor Browser legitimately starts Tor with DisableNetwork set, so Tor Browser will have time to ask the user whether they want to use bridges or proxies or etc before their Tor starts interacting with the network. So "well stop using that option then" is hopefully not our best plan.

But I wonder if there is a smarter way to have that phrased in the logs, so users have a better chance of guessing correctly what is going on.

(Long term we want to not send Tor Browser users to go read Tor's logs. But we're not there yet either.)

Child Tickets

Change History (16)

comment:1 Changed 20 months ago by antonela

Cc: antonela added

comment:2 Changed 20 months ago by arma

#24627 is a good straightforward example case of a user who thinks it's relevant enough to put in the ticket title.

And in fact that ticket illustrates another aspect of the issue, where a network team developer gets confused by the log message too.

comment:3 Changed 20 months ago by cypherpunks

Add DisableNetwork is unset? ;)

comment:4 Changed 20 months ago by catalyst

I think Tor Browser sets DisableNetwork whenever the configuration dialog is up, which can also happen if bootstrap failed for some reason.

comment:5 Changed 20 months ago by brade

Cc: brade mcs added

comment:6 Changed 16 months ago by nickm

Milestone: Tor: 0.3.6.x-final

comment:7 Changed 16 months ago by nickm

If anybody has a suggestion for better log behavior, it would probably be easy to implement.

comment:8 Changed 15 months ago by traumschule

After my monologue in #27351 i propose it to log "DisableNetwork is set. Network settings are opened or bootstrapping failed. Do we have connectivity? Tor will not make or accept non-control network connections. Shutting down all existing connections."

But this is even longer and should not appear every second. The connectivity test could be done by Tor and log that the guard is not reachable (anymore). Instead of proposing to set DisableNetwork=0 with stem or nyx the UI could offer a button "Enable Network" and show the error if it fails.

comment:9 in reply to:  8 Changed 15 months ago by catalyst

Cc: catalyst added
Keywords: s8-errors added

Replying to traumschule:

After my monologue in #27351 i propose it to log "DisableNetwork is set. Network settings are opened or bootstrapping failed. Do we have connectivity? Tor will not make or accept non-control network connections. Shutting down all existing connections."

I think this wording is too specific to Tor Browser and is not something that the tor daemon should use to log this event.

comment:10 Changed 15 months ago by nickm

Sponsor: Sponsor8-can

comment:11 Changed 13 months ago by nickm

Milestone: Tor: 0.3.6.x-finalTor: 0.4.0.x-final

Tor 0.3.6.x has been renamed to 0.4.0.x.

comment:12 Changed 11 months ago by gaba

Keywords: s8-errors removed
Sponsor: Sponsor8-canSponsor19

comment:13 Changed 10 months ago by nickm

Keywords: 040-deferred-20190220 added
Milestone: Tor: 0.4.0.x-finalTor: unspecified

Deferring 51 tickets from 0.4.0.x-final. Tagging them with 040-deferred-20190220 for visibility. These are the tickets that did not get 040-must, 040-can, or tor-ci.

comment:14 Changed 6 months ago by catalyst

Suggestion: remember the source of the DisableNetwork=1, e.g., command line, config file or controller connection, so we can log something like "command line set DisableNetwork" or "controller set DisableNetwork". Maybe even have an additional parameter to DisableNetwork so an application can put a user-friendly reason, e.g., "Tor Browser startup" (tor command line DisableNetwork 0 when Tor Browser starts up) or "Tor Browser config dialog".

Also, log a message when we set DisableNetwork=0. Right now a user has no way to tell from the log files that we turned DisableNetwork off.

comment:15 Changed 6 months ago by gaba

Keywords: ex-sponsor-19 added

Adding the keyword to mark everything that didn't fit into the time for sponsor 19.

comment:16 Changed 6 months ago by gaba

Keywords: ex-sponsor19 added
Sponsor: Sponsor19

Remove sponsor 19 and add a keyword ex-sponsor19 to mark all the tickets that could have been in the scope of the sponsor.

Note: See TracTickets for help on using tickets.