Bug #17516

Tor Browser takes a full CPU when running offline

Added by sajolida 2020-03-10 16:29:53 . Updated 2020-04-07 00:40:18 .

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
Target version:
Start date:
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Browser
Deliverable for:

Description

Steps to reproduce:

  • Start Tails 4.3 with no Internet connection.
  • Open the Tails documentation from the shortcut on the desktop.

Results:

  • Tor Browser (firefox.real) takes a full CPU, forever.

See screenshot in attachment.


Files

cpu.png (203858 B) sajolida, 2020-03-10 16:29:30

Subtasks


Related issues

Related to Tails - Feature #17330: Enable "bridge mode" by default Confirmed

History

#1 Updated by intrigeri 2020-03-27 11:17:44

  • Status changed from New to Confirmed

I can reproduce this.
I believe it’s because Tor Browser tries to talk to Tor, but we only start Tor when connecting to a network.

Would you agree that using Tor Browser while offline, in Tails, is a corner case?
I guess it’s mostly needed in order to read our documentation about how to fix one’s Internet/Tor connection.
Are there other use cases I’m missing?

#2 Updated by sajolida 2020-03-27 19:46:25

> Would you agree that using Tor Browser while offline, in Tails, is a corner case?

Yes!

> I guess it’s mostly needed in order to read our documentation about how to fix one’s Internet/Tor connection.

Read our documentation while being offline in general actually. For
example, SecureDrop people (Feature #17178).

> Are there other use cases I’m missing?

Tails developers working during long flights :)

This category of users would benefit from even a super hackish
workaround. I could give it a try myself at some point.

#3 Updated by intrigeri 2020-03-28 07:23:07

> This category of users would benefit from even a super hackish workaround. I could give it a try myself at some point.

Thank you for helping me prioritize this + what sort of fix/remediation would be acceptable.

Here’s a manual workaround that affected users could use: before starting Tor Browser, start tor: sudo systemctl start tor.

I’ve spent a few minutes thinking about how we could detect this situation and apply the workaround automatically. Unfortunately, it’s not easy because in the general case, we can’t distinguish “user did no connect to a Wi-Fi AP yet / plugged a network cable yet” from “user has no intention to connect to Internet”.

We can’t start tor by default all the time because the user may not have had a chance to configure bridges yet + we have plans to enable bridge mode by default.

A hack would be to start tor automatically when the user chooses “Disable all networking” in the Welcome Screen.
This requires manual intervention but it’s 4 clicks vs. setting an admin password + running a command in a Terminal.
It only helps users who’re aware of this.

Cost:

  • I think a 2 lines change in config/chroot_local-includes/lib/systemd/system/tails-unblock-network.service would be sufficient.
  • Usual overhead for code changes: building, testing manually, running CI, review.
  • Document this so that users who need it have a chance to learn about the fact the can “Disable all networking” to avoid this problem.

I don’t know if it’s worth the extra effort compared to documenting the manual workaround.

#4 Updated by sajolida 2020-04-01 22:10:39

#5 Updated by sajolida 2020-04-01 22:11:41

> Here’s a manual workaround that affected users could use: before starting Tor Browser, start tor: sudo systemctl start tor.

Nice! This solves my use case :)

> I don’t know if it’s worth the extra effort compared to documenting the manual workaround.

I don’t think so.

#6 Updated by intrigeri 2020-04-02 07:41:24

>> Here’s a manual workaround that affected users could use: before starting Tor Browser, start tor: sudo systemctl start tor.
>
> Nice! This solves my use case :)

:)

What’s the next step here? Do you want to document the manual workaround? Or shall we reject this issue?

#7 Updated by sajolida 2020-04-07 00:40:18

Next step: check if this issue is easier to fix once we enable bridge mode by default. By then, it might be easier to know whether people want to stay offline or not.