Opened 8 years ago

Closed 6 years ago

#3792 closed enhancement (duplicate)

Pre-launch Firefox and have it wait for Tor to connect

Reported by: phobos Owned by: mikeperry
Priority: High Milestone: TorBrowserBundle 2.3.x-stable
Component: TorBrowserButton Version:
Severity: Keywords: tbb-usability tbb-bounty
Cc: chiiph, arma, mikeperry, moritz@…, gnorcie@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

We probably already have this complaint, but I couldn't find an open ticket in trac. Consider this user feedback.

Ali from Tehran, Iran left a long, detailed voice mail today. He says the #1 reason people don't use Tor in Iran is because it takes too long to view a webpage. He's measuring the time as from the time he clicks on the 'Start tor browser' icon in windows xp through the time he can type in a url. It's taking him 60-90 seconds on average. He says he did 10 trials over three days.

He double-clicks 'start tor browser' and waits. He sees the vidalia control panel and the 0-100% progress bar, which takes 40 seconds on average in Tehran, and then nothing happens for 20 seconds, and then firefox starts up, and roughly another 10-30 seconds for check.torproject.org to load and tell him he's using tor. He can now type in a url and go to a website, such as balatarin.com, which will take anywhere from 10-30 seconds to load in TBB.

He compares this to his VPN. He clicks on the VPN icon, in 5 seconds it is connected. He starts up Firefox in 2 seconds. It takes 3 seconds to load the same site as he used to test before, balatarin.com.

10 second vs. 60-90 means no contest in his mind.

Child Tickets

Change History (28)

comment:1 Changed 8 years ago by mikeperry

Component: Tor BrowserTor bundles/installation
Owner: changed from mikeperry to erinn

To break this down, we've got five pieces of time consumption here, which are all accumulating serially:

  1. Vidalia launch time (minimal?)
  2. Tor network connection and descriptor download delay (40 seconds)
  3. Firefox launch delay (20 seconds?)
  4. circuit delay for check.tp.o (10-30 seconds)
  5. circuit delay for desired website (10-30 seconds)

The easiest way to improve this situation is to get things to start happening in parallel.

For #2, Tor should be creating test circuits using an existing stable or fallback consensus without the need to wait to download a very fresh one just to test network access. I thought there was some form of ticket for a long-term/fallback consensus, but I cannot find it.

For #3, Firefox should be being launched (or perhaps at least being cached into RAM by accessing all the associated files) while Tor is bootstrapping on the network.

For #4, Tor should be pre-creating a circuit suitable for check in all cases. I believe it already does this? In any case, we should perhaps also have the option to use the fallback consensus for actual circuits while Tor downloads a fresh consensus, or at least to be able to use it for check.

All of the above should perhaps be separate child tickets. Also, doing this is going to require a lot of coordination and integration testing to get right. Especially if we don't want the failure case of a user being given a Firefox window that might not work.. but perhaps a broken browser window is not bad if Vidalia can inform them later that Tor doesn't seem to be working and why, once it figures that out.

This will be a fairly large effort and will require a lot of coordination, but it is probably not impossible for us to drastically reduce the time to first page load.

comment:2 Changed 8 years ago by mikeperry

Owner: changed from erinn to karsten
Status: newassigned

I don't know who should own the cat-herding effort represented by this parent ticket. Maybe Karsten (as part of his project manager role?)

comment:3 Changed 8 years ago by mikeperry

Cc: chiiph arma added

This should probably be on your radar, chiiph.

You too, arma.

comment:4 Changed 8 years ago by mikeperry

Cc: mikeperry added

(Not sure if trac is smart enough to keep me Cc'd, not that I de-ownered myself)

comment:5 Changed 8 years ago by mo

Cc: moritz@… added

A suggested quick fix would be to write a new Windows launcher that starts Vidalia, Tor and Firefox in parallel instead of relying on Vidalia launching Tor and Firefox. Bonus feature: The launcher could display something resembling a progress bar.

In general, I believe the launcher is the culprit on all systems, and I don't see why Vidalia needs to be the one solution for everything as long as we have OS specific launchers.

I'm volunteering to look into that if you think a launcher like that would be helpful.

comment:6 Changed 8 years ago by Sebastian

This bug seems less about Vidalia start time, rather that Vidalia only starts launching firefox after Tor has connected successfully. This does make sense: Otherwise, you start Firefox, try loading check, but Tor hasn't connected or worse, maybe it can't start at all. For fast systems with slow internet connections this would be especially noticeable because firefox would be there immediately, and tor would take a while to connect.

This bug seems to be partially about "Tor takes too long to connect", which microdescriptors should help with - but they won't help in the instant-connectivity way of a VM

comment:7 Changed 8 years ago by Sebastian

(Is there a way to start Firefox "disabled" until we can somehow signal that tor is ready? I guess torbutton could poll for the bootstrap percentage or something, since it has the control pwd now?)

comment:8 Changed 8 years ago by mo

I'm thinking about writing and maintaining a small, OS specific launcher that starts all three processes in parallel and waits for their successful start. I could hide the windows of all three processes until Tor has finished bootstrapping.

Don't confuse this with a real fix. I'm suggesting a crude hack to help 90% (?) of all users affected by this issue.

comment:9 Changed 8 years ago by Sebastian

Sure. I'm just trying to prevent that by implementing some hack to help those users we make it harder for all the others.

comment:10 in reply to:  8 Changed 8 years ago by arma

Replying to mo:

I'm thinking about writing and maintaining a small, OS specific launcher that starts all three processes in parallel and waits for their successful start. I could hide the windows of all three processes until Tor has finished bootstrapping.

How do you know when Tor has finished bootstrapping?

The current situation is that Vidalia picks a control password for Tor, then launches Tor configured to use that control password. Then Vidalia is able to attach to the running Tor program.

The new situation with TBB is that Vidalia also launches Firefox with an env var that Torbutton can read to learn the control password that Vidalia picked.

So if we wanted to to launch everything independently, we would want the launcher to pick a control password, and then build a way for it to tell Vidalia what control password it picked.

comment:11 Changed 8 years ago by mo

I've done a small prototype in a Windows-only scripting language called AutoHotkey. It works as intendet. Chiiph and me were discussing a Windows-only plugin that:

a) gets called by Vidalia immediately after startup, and starts a hidden Firefox instance.

b) gets called by Vidalia again after Tor has bootstrapped to issue a page reload and unhide its windows.

I can do that in C. Objections?

comment:12 in reply to:  11 Changed 8 years ago by mikeperry

Replying to mo:

I've done a small prototype in a Windows-only scripting language called AutoHotkey. It works as intendet. Chiiph and me were discussing a Windows-only plugin that:

a) gets called by Vidalia immediately after startup, and starts a hidden Firefox instance.

b) gets called by Vidalia again after Tor has bootstrapped to issue a page reload and unhide its windows.

How would part b work? What IPC might we use between Vidalia and Firefox? I think we disable the normal Firefox remoting by using -no-remote..

We have to be extra careful with this piece. Failure to do this notification correctly could accidentally (and silently) break Torbutton's XHMLHTTPRequest to get the list of TBB versions for update notification (#3337).

comment:13 in reply to:  2 Changed 8 years ago by karsten

Owner: changed from karsten to mikeperry

Replying to mikeperry:

I don't know who should own the cat-herding effort represented by this parent ticket. Maybe Karsten (as part of his project manager role?)

I'm a terrible cat herder when it comes to things we haven't promised to a sponsor yet. Too many cats out there. For the moment, I'll write this ticket number on my list of things to suggest to Roger to suggest to our sponsor and pass back the crook (?) to Mike.

comment:14 in reply to:  7 ; Changed 8 years ago by arma

Replying to Sebastian:

(Is there a way to start Firefox "disabled" until we can somehow signal that tor is ready? I guess torbutton could poll for the bootstrap percentage or something, since it has the control pwd now?)

Mike, can you speculate on this? It seems that Vidalia should launch Firefox as soon as it learns the env vars it will pass. Then Torbutton should query the control port for bootstrap state when it starts up, and either display an interim 'Tor is starting' page or let it go directly to check.tp.o.

Unless it's harder to wedge Torbutton into those parts of Firefox than we hope?

comment:15 in reply to:  1 Changed 8 years ago by arma

Replying to mikeperry:

To break this down, we've got five pieces of time consumption here, which are all accumulating serially:
[...]

  1. Firefox launch delay (20 seconds?)

I wonder if we're seeing extra bad startup times because people are trying to launch their TBB from a slow USB key. I remember once upon a time people pointed out that Firefox from USB is especially slow because of all the tiny files it has to load. Is that still an issue? Does it have/want a ticket of its own?

In the mean time, suggesting "don't run it from your usb key if you don't like the bootup speed" is not a crazy idea.

comment:16 in reply to:  1 Changed 8 years ago by arma

Replying to mikeperry:

For #2, Tor should be creating test circuits using an existing stable or fallback consensus without the need to wait to download a very fresh one just to test network access. I thought there was some form of ticket for a long-term/fallback consensus, but I cannot find it.

See #572.

But what do you mean by 'test circuits'? Tor makes circuits to use them, and it should not make circuits with an old consensus -- see also #2878. And it shouldn't indicate 100% bootstrapped until it has a circuit that can be used.

For #4, Tor should be pre-creating a circuit suitable for check in all cases. I believe it already does this?

If you are unlucky enough to choose two exit relays that exit to 80 but not 443, then you won't have a preemptive circuit available. I guess we could kickstart ourselves with 80 *and* 443 -- somebody should sort out if that would give us more expected preemptive circuits or if it would be about the same number in practice.

In any case, we should perhaps also have the option to use the fallback consensus for actual circuits while Tor downloads a fresh consensus, or at least to be able to use it for check.

Building circuits using relays and keys from n days ago, where n is something your adversaries might find interesting about you, seems like a bad move here.

comment:17 in reply to:  14 Changed 7 years ago by mikeperry

Replying to arma:

Replying to Sebastian:

(Is there a way to start Firefox "disabled" until we can somehow signal that tor is ready? I guess torbutton could poll for the bootstrap percentage or something, since it has the control pwd now?)

Mike, can you speculate on this? It seems that Vidalia should launch Firefox as soon as it learns the env vars it will pass. Then Torbutton should query the control port for bootstrap state when it starts up, and either display an interim 'Tor is starting' page or let it go directly to check.tp.o.

Unless it's harder to wedge Torbutton into those parts of Firefox than we hope?

Hrmm.. Preventing any Firefox windows from launching probably will require a patch to Firefox. But this is doable. Is this the only thing we can parallelize?

comment:18 Changed 7 years ago by mikeperry

Component: Tor bundles/installationTor Browser
Milestone: TorBrowserBundle 2.3.x-stable

comment:19 in reply to:  description Changed 7 years ago by runa

Replying to phobos:

Ali from Tehran, Iran left a long, detailed voice mail today. He says the #1 reason people don't use Tor in Iran is because it takes too long to view a webpage. He's measuring the time as from the time he clicks on the 'Start tor browser' icon in windows xp through the time he can type in a url. It's taking him 60-90 seconds on average. He says he did 10 trials over three days.

Yeah, that's Windows XP for you. Wonder if there's anything we can do to speed things up?

comment:20 Changed 7 years ago by mikeperry

Component: Tor BrowserTorBrowserButton
Priority: normalmajor
Summary: TBB takes too long to start upPre-launch Firefox and have it wait for Tor to connect

Ok, here's the reduced plan:

Patch Firefox to allow it to be started windowless by Vidalia in parallel to Vidalia launching tor.

Have Torbutton poll on the control port with 'getinfo status/enough-dir-info' at 100ms intervals until the control port is open and responds that Tor is ready to build a circuit. (If you are such a purist that this amount of polling irritates you, then you just volunteered to write the first event-driven Tor controller in Javascript. Otherwise, I am open to suggestions for alternate polling intervals.)

When Tor is ready to launch a circuit, we can then launch the AJAX upgrade check and then just wait for completion of that before launching the first browser window.

In fact, I think the only new code I have to write for all of this to work will be the control port polling piece in Torbutton.

comment:21 Changed 7 years ago by mikeperry

As a stopgap, I've made the update check async at startup for Torbutton 1.4.6. We now check our version async on all New Window and New Identity invocations, as well. See #4718.

This should help browser window launch time quite a bit, I hope, but we still will likely want to launch the browser in parallel to Tor and have it poll for when it can actually open a window to improve further.

comment:22 Changed 7 years ago by mikeperry

Keywords: tbb-usability added

http://petsymposium.org/2012/papers/hotpets12-1-usability.pdf lists startup/launch time as the #1 "stop point" where people had problems/confusion while using TBB. They also think we should have a dialog of some sort until the browser is actually usable. Probably not the worst idea, but their results also seems to suggest the current Vidalia 0.2.x progress bar UI is insufficient for this purpose by subtext, since it was present for their testing.

comment:23 Changed 7 years ago by arma

Cc: gnorcie@… added

comment:24 in reply to:  21 ; Changed 7 years ago by arma

Replying to mikeperry:

we still will likely want to launch the browser in parallel to Tor and have it poll for when it can actually open a window to improve further.

It can't be quite in parallel, since Vidalia needs to learn the controlport from Tor so it can pass it to Firefox when it launches Firefox.

But that should only be a minor delay.

comment:25 in reply to:  24 Changed 7 years ago by greg

Replying to arma:

Replying to mikeperry:

we still will likely want to launch the browser in parallel to Tor and have it poll for when it can actually open a window to improve further.

It can't be quite in parallel, since Vidalia needs to learn the controlport from Tor so it can pass it to Firefox when it launches Firefox.

But that should only be a minor delay.

Hi all. Thanks to Roger for the CC.

My name is Greg, and I authored the paper listed above.

~40% of the users listed this as an issue. I understand that for technical reasons, Tor and Vidalia can't launch at exactly the same moment. But if their launches can be at all parallelized, it would not only solve this ticket, but have a great impact on several other problems.

For example, in a study I ran, users would start the Tor Browser Bundle. Vidalia would tell them they were "connected to the tor network", but the custom Firefox would not have yet launched. So they'd erroneously decide that all their traffic was anonymous, and open up Chrome, Firefox, or *shudder* IE.

IMHO, anything that reduces that delay will be helping eliminating one of the biggest usability issues in the TBB. I just downloaded the latest TBB, and it seems like the time between Vidalia connecting and TBB opening is _much_ shorter. Is this just a fluke, or has the new TorButton code mentioned above gone live?

comment:26 Changed 6 years ago by mikeperry

Keywords: tbb-bounty added

comment:27 Changed 6 years ago by mikeperry

#6009 will eliminate the need for this.

comment:28 Changed 6 years ago by mikeperry

Resolution: duplicate
Status: assignedclosed

#6009 is done. Calling this a duplicate.

Note: See TracTickets for help on using tickets.