TBB with -allow-remote conflict with Firefox and leak opened pages to it

How to reproduce: install Firefox (not Iceweasel, binary from mozilla.org, or Ubuntu package), open it, then run TBB with -allow-remote 'https://torproject.org'. It opens new tab in Firefox, when it should run Tor Browser.

It causes major problems if you want to use torbrowser-launcher as your default browser, there is issue for it https://github.com/micahflee/torbrowser-launcher/issues/157

Building Firefox --with-app-name=torbrowser and --with-app-basename=torbrowser fix that. It shouldn't cause any fingerprinting issues.

added component::applications/tor browser owner::mikeperry priority::medium resolution::worksforme severity::normal status::closed tbb-usability-stoppoint-app tbb-usability-stoppoint-navigation type::defect labels

Aha! We have a few different remoting issues piling up. If these config flags do indeed fix some/all of them, we can try this out on 4.5a5.

Trac:
Cc: N/A to special
Keywords: N/A deleted, TorBrowserTeam201503, tbb-4.5-alpha added

mcs - what makes you think this is risky (as per your comment in https://trac.torproject.org/projects/tor/ticket/14631#comment:13)?

Trac:
Cc: special to special, mcs, brade

Replying to mikeperry:

mcs - what makes you think this is risky (as per your comment in https://trac.torproject.org/projects/tor/ticket/14631#comment:13)?

Just that it is a major change in behavior, so the potential issues are somewhat unknown. It does seem like the right direction for Tor Browser, and probably packages like iceweasel already use these configure flags. Also, Kathy and I used them some years ago when we built a custom browser for someone else. We would need to figure out the exact case and spacing that is appropriate, e.g., should we use --with-app-name=torbrowser or --with-app-name="Tor Browser" and so on.

If we do this, someday soon we can consider allowing remoting by default.

On the assumption that this isn't user-facing, it probably is safest to go with torbrowser or TorBrowser. I can give that a whirl in a test build and see if anything explodes on Linux, at least.

Trac:
Owner: tbb-team to mikeperry
Status: new to assigned

Trac:
Keywords: N/A deleted, MikePerry201503 added

I changed my mind. I think matching the display name of "Tor Browser" is safest, despite the space, since while looking into these config options I found some Mozilla bugs where they were sometimes using the wrong type of name (appname vs basename vs display name) in various places in the code. So having them all match seems to actually be smarter on balance. Hopefully the space won't cause any surprise remoting issues..

FYI: I have a patch to do this in mikeperry/bugs13375+14977+15029. That branch is accumulating a bunch of changes in it because I want to test this along side a few other bug fixes in a full build. I will likely add #14631 (moved) to the mix as well.

Bad news, it seems that mcs and brade were right to be wary of this change. If we use spaces in --with-app-name, the build completely breaks. And changing --with-app-name to anything changes the firefox.exe to that name, which means we have to update all of our launchers and shortcuts on all platforms if we do this change.

--with-app-basename seems fine with spaces, and doesn't seem to affect the build. I'm not sure if it is enough to fix remoting by itself, though.

Removing this off our radar for now. It won't make it into 4.5. :/.

Tagging this with two usability stoppoint tags so we revisit it later, because it both prevents TBB from being a proper "default browser", as well as handling links/navigation directives from other apps.

Trac:
Keywords: TorBrowserTeam201503, MikePerry201503, tbb-4.5-alpha deleted, tbb-usability-stoppoint-app, tbb-usability-stoppoint-navigation added

Hm.. Is this still an issue? It seems Debian testing is shipping Firefox now and having that one open and starting the Tor Browser with --allow-remote foo.com opens foo.com in Tor Browser.

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

Replying to gk:

Hm.. Is this still an issue? It seems Debian testing is shipping Firefox now and having that one open and starting the Tor Browser with --allow-remote foo.com opens foo.com in Tor Browser.

On OS X, I'm not able to reproduce the original problem of pages opening in another Firefox. However, I can't get pages to open in an existing Tor Browser even with --allow-remote - there is always an error about another instance of Tor Browser running. Is that a separate bug?

Replying to special:

Replying to gk:

Hm.. Is this still an issue? It seems Debian testing is shipping Firefox now and having that one open and starting the Tor Browser with --allow-remote foo.com opens foo.com in Tor Browser.

I suspect the addition of --class "Tor Browser" to the commands in the Linux start-tor-browser fixed this. But see #17891 (moved).

On OS X, I'm not able to reproduce the original problem of pages opening in another Firefox. However, I can't get pages to open in an existing Tor Browser even with --allow-remote - there is always an error about another instance of Tor Browser running. Is that a separate bug?

Maybe. But I get that same error with the Firefox 45.0.1 when I just run a command like: /Applications/Firefox.app/Contents/MacOS/firefox https://google.com/ I am not sure, but I don't think this has ever worked on Mac OS X. See https://bugzilla.mozilla.org/show_bug.cgi?id=238992 for a similar question (the answer: "use Apple Events")

Replying to mcs:

Maybe. But I get that same error with the Firefox 45.0.1 when I just run a command like: /Applications/Firefox.app/Contents/MacOS/firefox https://google.com/ I am not sure, but I don't think this has ever worked on Mac OS X. See https://bugzilla.mozilla.org/show_bug.cgi?id=238992 for a similar question (the answer: "use Apple Events")

Ah, you're correct. I'm able to open a tab on OS X with open -a TorBrowser https://google.com. Sorry for the noise. It does look like this bug might be fixed?

Yes, I think so.

Trac:
Resolution: N/A to fixed
Status: assigned to closed

start-tor-browser --allow-remote [url] does NOT work (anymore?) on linux.

Tor Browser is already running, but is not responding. To open a new window, you must first close the existing Tor Browser process, or restart your system.

Somebody also recreated that torbrowser-launcher issue referred to in the ticket above, it's most likely related: https://github.com/micahflee/torbrowser-launcher/issues/245

Trac:
Username: zhr

It does appears again en 9.00 I have to downgrade to 8.5.5

How to reproduce:

• Platform: Windows 10
• Install Mozilla Firefox 70.0 (64-bit)
• Install Tor Browser 9.0
• Open a Mozilla Firefox window
• Run: "C:\path\to\Tor Browser\Browser\firefox.exe" --allow-remote https://check.torproject.org/
• It opens https://check.torproject.org/ in Firefox instead Tor Browser

Trac:
Resolution: fixed to N/A
Status: closed to reopened

Replying to cypherpunks:

It does appears again en 9.00 I have to downgrade to 8.5.5

How to reproduce:

• Platform: Windows 10
• Install Mozilla Firefox 70.0 (64-bit)
• Install Tor Browser 9.0
• Open a Mozilla Firefox window
• Run: "C:\path\to\Tor Browser\Browser\firefox.exe" --allow-remote https://check.torproject.org/
• It opens https://check.torproject.org/ in Firefox instead Tor Browser

Please open a new bug in case 9.0 is suddenly breaking behavior. That said, I just tested your steps and I can't reproduce the issue on a Windows 7 machine. The second difference that might be relevant here is that I first tested in a 8.5.5 bundle (it worked) and then upgraded that one to 9.0 (it still worked). Maybe you used a fresh 9.0 where the problem then occurred (although that would be unexpected).

I am closing this as worksforme now. If the issue continues to be a problem, please open a new ticket. Ideally with steps to reproduce that allow me to see your bug, too.

Trac:
Resolution: N/A to worksforme
Status: reopened to closed

closed

moved to tpo/applications/tor-browser#14977 (closed)