Opened 12 months ago

Last modified 5 weeks 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
Cc: antonela, brade, mcs, catalyst Actual Points:
Parent ID: Points:
Reviewer: Sponsor: Sponsor19

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 (13)

comment:1 Changed 12 months ago by antonela

Cc: antonela added

comment:2 Changed 12 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 12 months ago by cypherpunks

Add DisableNetwork is unset? ;)

comment:4 Changed 12 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 12 months ago by brade

Cc: brade mcs added

comment:6 Changed 7 months ago by nickm

Milestone: Tor: 0.3.6.x-final

comment:7 Changed 7 months ago by nickm

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

comment:8 Changed 7 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 7 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 6 months ago by nickm

Sponsor: Sponsor8-can

comment:11 Changed 5 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 2 months ago by gaba

Keywords: s8-errors removed
Sponsor: Sponsor8-canSponsor19

comment:13 Changed 5 weeks 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.

Note: See TracTickets for help on using tickets.