Bug #814
openThe Waiting for Orbot message is not being dismissed when Orbot is ready
0%
Description
When toggling thw proxy setting to TOR in PB notification "waiting for Orbot to connect" appears and can be removed by clicking anywhere else on the screen, but pops up again if you leave-return to PB. Orbot is running. And PB is being routed through TOR, I can tell by WebRTC leak being fixed.
Also interesting observation. WebRTC leak still happens when rules in Netguard are not applied to PB and/or allowed for current devices connection.
So to fix the WebRTC leak PB has to have TOR toggled on, and be blocked in Netguard.
Updated by Soren Stoutner over 2 years ago
Please attach a copy of About > Config from inside the app.
Regarding WebRTC, I recommend you take a look at https://www.stoutner.com/webrtc/.
Updated by Air Yes over 2 years ago
Here:
Privacy Browser
Version 3.9 (version code 57)
Hardware
Brand: google
Manufacturer: Google
Model: Pixel 5
Device: redfin
Bootloader: r3-0.4-7758093
Radio: g7250-00161-211008-B-7807492
Software
Android: 12 (API 31)
Security Patch: 2022-02-05
Build: SQ1A.220205.002.2022030501
WebView Provider: app.vanadium.webview
WebView Version: 99.0.4844.58
Orbot: 16.6.0-RC-2-tor.0.4.6.9
Memory Usage
App Consumed Memory: 14.27 MiB
App Available Memory: 17.41 MiB
App Total Memory: 31.68 MiB
App Maximum Memory: 256.00 MiB
System Consumed Memory: 5,245.00 MiB
System Available Memory: 2,183.11 MiB
System Total Memory: 7,428.11 MiB
Blocklists
EasyList: 202111230139
EasyPrivacy: 202111230139
Fanboy’s Annoyance List: 202111230200
Fanboy’s Social Blocking List: 202111230139
UltraList: 1
UltraPrivacy: 2
Package Signature
Issuer DN: CN=FDroid, OU=FDroid, O=fdroid.org, L=ORG, ST=ORG, C=UK
Subject DN: CN=FDroid, OU=FDroid, O=fdroid.org, L=ORG, ST=ORG, C=UK
Start Date: Apr 17, 2016 4:14:13 AM EDT
End Date: Sep 3, 2043 3:14:13 AM EST
Certificate Version: 3
Serial Number: 166629308
Signature Algorithm: SHA256withRSA
Updated by Soren Stoutner over 2 years ago
Privacy Browser is supposed to show the Waiting For Orbot message anytime that Orbot reports the connection is not established. It will then disappear as soon as Orbot reports the connetion is established. So, if Orbot is not ready, which can happen if it is just starting up or if the connection was shut down because it was idle in the background for too long, then the message will appear for a few moments and then disappear as soon as Orbot can handle the data. Apparently this isn't working correctly, possibly relating to the upgrade to Orbot 16.6.0-RC-2-tor.0.4.6.9 or possibly relating to something else. I will have to look into it deeper.
In the meantime, you can bypass the message by using a custom proxy as described at https://www.stoutner.com/privacy-browser-android/common-settings/proxy-config/.
Updated by Soren Stoutner over 2 years ago
- Tracker changed from Feature to Bug
- Subject changed from TOR Proxy Orbot notification to The Waiting for Orbot message is not being dismissed when Orbot is ready
Some minimal testing indicates that if Orbot is not connected when Privacy Browser starts then it the dialog appears and disappars as expected. However, if the Orbot is already connected when Privacy Browser starts then it doesn't pick up on the message. My guess is that this is a bug in Orbot. When Privacy Browser starts it asks Orbot to establish a connection. Previously, and according to their documentation, Orbot will respond with a connection ready message if it is already connected. However, this isn't currently happening if Orbot is already running.
Significantly, this problem doesn't manifest with basic testing for Orbot 16.4.1-RC-2-tor.0.4.4.6. My guess is this is just a passing bug and they will figure it out, but if the next release of Orbot doesn't resolve the issue I will probably contact them and file a bug report.
Updated by Air Yes over 2 years ago
Ok, makes sense just got orbot update to Orbot-16.6.0-RC-3-tor.0.4.6.9-fullperm-arm64-v8a-release on github fixed the issue.
Thank you.
Updated by Air Yes over 2 years ago
Regarding WebRTC thank you for the article, please do more educational stuff like this.
Still not clear on the webview though. In my case PB is relying on vanadium webview which shouldn't have the WebRTC leak, at least vanadium browser(in any security mode) itself is not leaking WebRTC with same network setup.
Updated by Soren Stoutner over 2 years ago
- Status changed from New to In Progress
- Assignee set to Soren Stoutner
In relation to Vanadium WebView, I don't know exactly what modifications they are making to the Chromium code to build it. That is probably a question that is better directed to them.
Updated by Air Yes over 2 years ago
Agree but I think since they build it closed source I'm not sure they'd reveal. By the way the waiting for orbot happened again I tried to set a custom proxy. Deaukt custom proxy was http://localhost:8118 i tried no connection. Changed tohttp://localhost:9050 same had to switch back to proxy TOR.
Updated by Soren Stoutner over 2 years ago
Vanadium is open-source. https://github.com/GrapheneOS/Vanadium
The default proxy for Orbot (unless you have changed it in the Orbot app) is socks://localhost:9050. Note that it is not http://.
Updated by Soren Stoutner over 2 years ago
In my testing, the problem is not fixed in Orbot 16.6.0-RC-4-tor.0.4.6.9.
I have submitted an Orbot bug report at https://github.com/guardianproject/orbot/issues/637.
Updated by Soren Stoutner over 2 years ago
- Status changed from In Progress to Closed
The problem is fixed with Orbot 16.6.1-RC-3-tor.0.4.6.10.
Updated by Soren Stoutner over 2 years ago
- Status changed from Closed to In Progress
Scratch that. Orbot 16.6.1-RC-3-tor.0.4.6.10 fixes the original bug but introduces the opposite bug.
Specifically, if Orbot is not running and is started by Privacy Browser with the "org.torproject.android.intent.action.START" intent, it starts and connects but never broadcasts the "ON" status update when it connects.
If Orbot is already running but not connected, it connects and correctly broadcasts the "ON" status updated. If it is already connected it correctly broadcasts the "ON" status update.