Gedsh
"Route all traffic through tor" when tor not running, still passes on traffic
This may have been a deliberate choice, but I think it is wrong behavior to have Invizible pass through (allowed, in case of firewall) traffic to the network when tor is not running and "Route all traffic through tor" is checked.
The VPN options allow setting a kill-switch to ensure network traffic is routed. However, accidentally tapping the tor checkbox (thus turning it off) is enough to deanonymize app traffic. This may result in unnecessary accidents. It would probably be better to warn user if tor is turned off and "Route all traffic through tor" option is checked. This would be more in line with the intentions of the kill-switch.
I have no plans to change how InviZible works, but I do plan to add a firewall option that allows the app to connect only through Tor.
I have no plans to change how InviZible works, [..]
That's fair. My intention is to point out a possible oversight. At the moment, users who rely on certain apps to connect anonymously only, may be at risk.
[..] but I do plan to add a firewall option that allows the app to connect only through Tor.
That would accomplish the same thing on a more granular basis. That seems like a fine addition.
Considering #402 and your response, I am not sure I understand the function of this checkbox.
If checked, it means all apps are routed. Then, if tor is enabled, it would route all apps through tor. However, if not checked, it routes unselected apps as-if directly, unless blocked by firewall. Unless restricted by firewall, it would be same as no kill-switch. So the kill-switch in Android essentially is a mechanism to ensure InviZible gets full control and InviZible can still decide to restrict (firewall) or route directly (no tor).
How is stopping/disabling tor now different from routing directly?
I understand the checkbox to disable tor on Main-tab. However, checkbox "Route all traffic through tor" does not offer the function it claims to, and I cannot find further nuance. I do not know how to explain it other than:
- If site/app selected or if "route all traffic" checked, then route via tor.
- Otherwise: route directly.
Note also, there is only one list: (Right?)
- If "route all traffic", then lists are for exclusion.
- If "route all traffic" not selected, then lists are for inclusion.
With my current understanding, I can only see this as being a bug.
I can only see this as being a bug.
If you consider that a bug is something that is clearly described in the app manual, then the problem is not with the app, but with your understanding of how the app works, or your unwillingness to read the documentation.
https://github.com/Gedsh/InviZible/wiki/VPN-mode-(no-root-required)
In any case, I understand your concerns. The main problem is that not everyone uses Tor, so when they enable only DNSCrypt, their phone traffic will be blocked because routing all apps through Tor is enabled by default.
If I disable routing all apps through Tor, new users who run Tor will not understand why their IP address has not changed.
So I have no plans to change the existing behavior, as it is more intuitive for new users. The only solution is to add a corresponding option to the firewall. But I am open to new ideas that would be more convenient. Perhaps I could add one general option for all apps that work through Tor.
If you consider that a bug is something that is clearly described in the app manual, then the problem is not with the app, but with your understanding of how the app works, or your unwillingness to read the documentation.
Considering your response (above), I think you might mistake my comment (below) for an attack. Just in case, let me say: It is not. It is merely a direct conclusion following an explanation https://github.com/Gedsh/InviZible/issues/398#issuecomment-3582676744 .
With my current understanding, I can only see this as being a bug.
Considering your response (above), I think you might mistake my comment (below) for an attack. Just in case, let me say: It is not. It is merely an direct conclusion following an explanation https://github.com/Gedsh/InviZible/issues/398#issuecomment-3582676744 .
To tackle (above) comment first: in my understanding, I missed an aspect in my explanation, namely that other (presumably non-routable) traffic is blocked. I would argue that if an app is selected to route through tor (include-list) then you would always want that behavior. I would think nothing good can come from partially routing an app based on supported protocols/traffic. So, it's tightly connected to using tor, whether by include-list of route-all-traffic checkbox.
Arguably, if an app wants to do both, they would need to distinguish between types of traffic in-app, and would likely offer a way to configure a proxy for the alternative route to tor.
[..] The main problem is that not everyone uses Tor, so when they enable only DNSCrypt, their phone traffic will be blocked because routing all apps through Tor is enabled by default.
The use-case you explain here is valid, but your checkbox says something else. Let me explain:
I agree, obviously, that if someone does not want to use tor, traffic should be forwarded directly. But I think your solution is suboptimal and introduces a risk.
If your goal is: "if a user does not want/need to use tor, it must be unmistakably clear that the "Route all traffic through tor"-checkbox must also be disabled." That is, there must be no confusion. I am thinking along the lines of:
- If
"auto-start tor" toggleisoff, check and inform if"Route all traffic through tor"ison, that only excluded apps will have network access until tor is manually started. (exceptional configuration) - If
"hide IP with tor" checkboxisoff(i.e. process is not running), check and inform if"Route all traffic through tor"ison, that only excluded apps/sites have network access at that moment. - If
"apps selected for tor" or ("Route all traffic through tor" AND apps not selected for exclusion), block app if tor is not running. Again, I think there is risk in letting traffic pass for apps that one thinks are set up to use tor.
In short: you would unnecessarily complicate the app if you also introduce the firewall-controls, in my understanding.
Alternatively, you could say: I want this all managed through the firewall, but then your "Route all traffic through tor"-checkbox and inclusion-/exclusion-lists (for apps, at least) no longer seem necessary.
It would depend on the premise of whether you choose a strict separation of networks for an app. How often is fluidly/ad-hoc switching between tor and plain network actually a benefit rather than a risk? In terms of security-guarantees, tor offers higher quality, so downgrading is usually a deliberate action and careful consideration.
Again, the choice is yours, of course. I am simply explaining the situation as I see it.
check and inform
It doesn't make sense to inform new users about such features, as most of them won't understand what it means right after installing the app. After using the app for a while, users will want to read the documentation to learn how to use the app more effectively. That's why I don't like your idea. The app should be simple and as intuitive as possible for new users. That's my point.
It doesn't make sense to inform new users about such features, as most of them won't understand what it means right after installing the app. After using the app for a while, users will want to read the documentation to learn how to use the app more effectively.
I think there is a lower chance that your user will read the wiki/documentation than the in-app hints. Your hints will also guide them if they misunderstand, possibly also misunderstand the documentation. It serves both as check for settings and for the user's (mis)understanding as well as forgetting other relevant settings.
That's why I don't like your idea. The app should be simple and as intuitive as possible for new users. That's my point.
I understand that you want to make it easy for users, but you make it just as easy to make costly mistakes.
And it assumes that there is no technical failure that causes tor to stop, because that failure is costly to no fault of users.
Hey, on a side-note. I think we understand each-other's viewpoints. Unless you surprise me with your arguments or you want me to clarify my previous comments further, I think I have said/clarified everything concerning this topic. Regardless of what you choose, thanks for following up in the discussion.