Tor Browser on Android does not open links from other applications

added 13.5 stable 14.0 stable Bug UX labels

added Android label

added Next label

Is there further work we need to do here to prevent to-browser from being listeed as a possible handler for URLs?

For some strange reason it works now as expected. Whenever I restarted the browser yesterday I had the above described behavior. Today I can't reproduce it. It opens a new tab like it should.

I was able to reproduce it now and maybe it has something to do with #42593 (closed):

Open Tor Browser with bridges set (doesn't matter which kind of bridges).
Open some random website or click on a link in an external application. (works fine)
Go to settings and disable bridge settings.
Go to another application and click on a link. Now Tor Browser opens, but no site is loaded nor a new tab is opened.

assigned to @dan

This seems like a priority for the forthcoming 13.5 and some mismatch issue and side effect of configuration mapping in GV vs in firefox-android

added Doing label and removed Next label

All the above I assume with the Tor Browser being set as the system-wide default browser, right?

actually after doing some testing trying to replicate, I think it might be a bootstrap issue. If we bootstrap with bridge, then turn it off, I suspect tba is now trying to hit up sites with out a bridge, but we essentially need to rebootstrap. How does desktop handle this. @pierov is this a case of that apply/save paragigm you were talking about. where in this case it saves the settings but doesn't send them to ctor, so I need to check how I'm saving this particular setting?

@dan If I understand correctly, on desktop settings are applied to tor immediately as they are changed in the about:preferences frontend:

If I understand correclty it looks like we have separate save vs apply flags coming in from the Android side:

https://gitlab.torproject.org/tpo/applications/tor-browser/-/blob/tor-browser-115.11.0esr-13.5-1/toolkit/modules/TorAndroidIntegration.sys.mjs?ref_type=heads#L158

In this case 'save' is saving user settings to about:config prefs, whereas 'apply' is pushing them down to the tor-daemon.

but if we've bootstraped with a bridge, I don't think we rebootstrap. And We'd need to if we were changing how we connect?

more confusingly, using obfs4, connecting to a site, the circut pane shows: bridge: obfs: ip country: ip country: ip dest

but removing the bridge in the config and reclicking the circut display, the circuit to the site (not reloaded) has changed to different country: different ip different country: different ip different country: different ip dest

but the tor logs don't show any bootstrapping activity

more confusingly holding open the circuit display shows an at time rapidly changing circuit like on https://www.showmyip.com/.

So the UI isn't very clear whats happening but I'm pretty sure just removing a bridge doesn't rebootstrap, it saves that info for next time? unless bridges can just be removed for each new circuit?

we essentially need to rebootstrap

Bootstrap isn't really an explicit thing on C tor .

Connecting is SETCONF DisableNetwork=0 and canceling a bootstrap is SETCONF DisableNetwork=1.

On desktop, we just push the new settings, and the tor daemon will start applying them. I think it invalidates circuits (the logs say something about a change of guard context) and starts opening new circuits going through the bridge:

[notice] Switching to guard context "bridges" (was using "default")

On the other hand, if I understand correctly, going to the settings on Android, cancels the bootstrap, which is good if we haven't bootstrapped yet, but it's bad if we had bootstrapped and then we just want to update the configuration.

Even though we don't check in TorProvider.stopBootstrap if we did finish bootstrap successfully before setting DisableNetwork, this method is intended to be called only by TorConnect (and so it seems to be), which refuses to do anything if we're not in a bootstrap phase (Henry's good call).

Indeed, I can see:

05-29 09:35:52.202  4413  4715 I Gecko   : console.warn: TorConnect: Cannot cancel bootstrapping in the Bootstrapped state

I guess this is an adapter problem (the TAS implementation used to kill the daemon and restart it with an updated configuration, rather than using a SETCONF).

I'm not sure doing something more about this will help, but I hope it's a good starting point.

About the circuits: we don't have a nice way to print them, but I've opened an issue+MR (#42604 (closed), !1031 (merged)) to add a couple of additional log messages.

Right now we have entries like:

05-29 10:14:08.440  9539  9561 I Gecko   : console.debug: TorDomainIsolator: 
05-29 10:14:08.440  9539  9561 I Gecko   :   Requested http://tb-build-03.torproject.org/ via torproject.org:0:503cd809935bba7a1bff4abceabe4279fd44486ec8aaeca2239edca052e69bf9
05-29 10:14:08.465  9539  9561 I Gecko   : console.debug: TorDomainIsolator: 
05-29 10:14:08.465  9539  9561 I Gecko   :   Requested https://tb-build-03.torproject.org/~pierov/ via torproject.org:0:503cd809935bba7a1bff4abceabe4279fd44486ec8aaeca2239edca052e69bf9
05-29 10:14:09.021  9539  9561 I Gecko   : console.debug: TorDomainIsolator: 
05-29 10:14:09.021  9539  9561 I Gecko   :   Requested https://tb-build-03.torproject.org/icons/blank.gif via torproject.org:0:503cd809935bba7a1bff4abceabe4279fd44486ec8aaeca2239edca052e69bf9
05-29 10:14:09.022  9539  9561 I Gecko   : console.debug: TorDomainIsolator: 
05-29 10:14:09.022  9539  9561 I Gecko   :   Requested https://tb-build-03.torproject.org/icons/back.gif via torproject.org:0:503cd809935bba7a1bff4abceabe4279fd44486ec8aaeca2239edca052e69bf9

My MR introduces further log messages, to associate those SOCKS credentials to the actual circuit:

05-29 10:14:05.627  9539  9561 I Gecko   : console.debug: TorDomainIsolator: 
05-29 10:14:05.627  9539  9561 I Gecko   :   Updating circuit torproject.org:0|503cd809935bba7a1bff4abceabe4279fd44486ec8aaeca2239edca052e69bf9
05-29 10:14:05.627  9539  9561 I Gecko   : Array
05-29 10:14:05.627  9539  9561 I Gecko   :     - 0 = {"fingerprint":"2D82C2E354D531A68469ADF7F878FA6060C6BACA","ipAddrs":["193.11.166.194"],"bridgeType":"obfs4","regionCode":"SE"}
05-29 10:14:05.627  9539  9561 I Gecko   :     - 1 = {"fingerprint":"99F957E4233BD5F67EEE033894CB376A786FF687","ipAddrs":["23.227.186.194"],"bridgeType":null,"regionCode":"US"}
05-29 10:14:05.627  9539  9561 I Gecko   :     - 2 = {"fingerprint":"57AA63FBC1776C286ABE6D60768CD8236B3BFA46","ipAddrs":["185.220.101.23","2a0b:f4c2::23"],"bridgeType":null,"regionCode":"DE"}
05-29 10:14:05.627  9539  9561 I Gecko   :     - length = 3

(they are gated in the debug level of the logs, which can be enabled by setting browser.tordomainisolator.loglevel to all).

I'm not sure doing something more about this will help, but I hope it's a good starting point.

Maybe not...

I've tried to reproduce a little bit more: changing other settings, such as quickstart, doesn't change anything.

In general, it doesn't seem like a tor integration backend problem to me: we're not moving to the correct tab, but the connection is still active and works as expected.

Could have something happened related to app navigation when moving the bridge settings outside of their own fragment to the main settings panel?

I don't think this is a problem with the bridges actually (tho after staring at that code I have some improvements). I can recreate this just by:

bootstrapping tor browser
setting as default browser
open link from another app in tba (like from slack)
trying that again from same app or other

and now sometimes I just get the punted into tba and a blank tab

also I can recreate this on my phone in stable so it's not a alpha regression.

added Next label and removed Doing label

added 14.0 stable Backport labels

marked this issue as related to #42753 (closed)

mentioned in issue #42753 (closed)

removed 13.5 stable label

added 14.5 stable Roadmap::Future labels

removed Next label

removed the relation with #42753 (closed)

mentioned in issue #43327 (closed)

marked this issue as related to #43327 (closed)

removed 14.0 stable label

removed Backport label

added Linkability label

added Apps::Type::Bug label

We no longer allow opening links from other applications in Tor Browser due to linkability concerns.

closed

Tor Browser on Android does not open links from other applications

Designs

Child items ...

Activity