This proposal for hotspot VPN support is the wrong approach and bad for privacy. That's why it isn't accepted. The existing implementations are also leaky so those cannot be used. As always, we want to implement features in a way that's done properly and does what users actually want rather than making them think they're getting what they want when it isn't. Do you want to have everything tied together with a single exit IP and more leaks rather than fixing them all?
Rejecting a badly designed privacy feature which is done in an anti-privacy way and unnecessarily ties devices together is the opposite of theater. In GrapheneOS, we care a lot about implementing things correctly and not misleading users about what's provided. We want to provide a better form of this feature than what people are asking for but it's very difficult to provide a good feature within the way app-based VPNs work on Android. We're busy fixing upstream leaks.
We need to fix several different forms of leaks in the Android VPN system. Adding a major new feature with an improper design and leaks is the opposite of what we want.
We have to choose what to prioritize and how to design the features we include. We were responding to someone that's proposing we choose our priorities and how to design features based on opening up a voting system to everyone.
Why should people who aren't experts or doing any work decide on what to do?
Not implementing an anti-privacy approach to providing a hotspot connection with a VPN is not security at the expense of freedom. It's caring about doing things properly.
It does not make sense to route a bunch of devices through the Owner user VPN with no support for separate VPN routes. It encourages an approach which hurts privacy instead of improving it by supporting finer-grained isolation. The status quo on Android is that each profile has an entirely separate VPN.
You're welcome to get involved with development and help us implement a proper tethered device VPN feature meeting our standards. What we've rejected is including the implementation from LineageOS due to major flaws with it. We do not include code not meeting our standards and expect features to be designed/implemented to meet high standards. You're welcome to make your own builds including a bunch of LineageOS code not meeting our standards. You already have that freedom.
Since GrapheneOS is open source, there are 2 paths someone could take:
1) Make your a fork including a bunch of LineageOS code not meeting our standards for reasons we've communicated quite well
2) Help us with high priority VPN related development work and then implement a better version of this feature meeting the standards of GrapheneOS
Most of our users appreciate our high standards and can understand that it takes longer to ship features when done properly.
From what I can see, the OP just wanted to be able to "share VPN with hotspot devices" because "my tethered device can't easily add a VPN".
I think if you cared a bit more about quality-of-life and usability, more people would want to use it.
But of course, it's your project(TM), and I don't have a say because I don't contribute to it.
Which is fine. Like I said, I don't seem have a working phone anymore. So I have no reason to care.
Because users, who in many cases rely on the software for important things, are stakeholders.
But of course, it's completely up to you what governance structure you have.
It's important to implement it well regardless of the reason they want to have it. It will be widely perceived as a privacy feature and used as one. We don't want to make things worse than they already are. We do care a lot about usability and compatibility. We prioritize that based on what impacts the most people and makes the biggest difference, and we're not willing to compromise our principles so some things take a long time to implement to do it properly.
It still needs to be done properly in way that's not a major liability for us to include it. Most people will use it as a privacy feature even if the impact on privacy is negative compared to doing it another way.
There are high priority issues to fix with Android VPN support and we can't afford to add new ones we know exist with that feature while making it even harder to fix the existing issues.
Perhaps you haven't seen the hard work we're putting into leak blocking.
@Hyolobrika Do you think that GrapheneOS is some kind of democracy or that the users are somehow owed every feature they request? I'm confused here.
@Hyolobrika Then I'm not sure what work the term authoritarian is doing here. It just seems like a buzzword. And, like all buzzwords, it's not clear that it scopes over the example provided, and if it does scope over the example provided, it would also scope over other hilarious (unintended) things that make it absurd to apply to begin with. 🤷♂️
@Hyolobrika data privacy is not on your list? or using old devices? Buy a new pixel phone and don't install 3rd party OS.
@GrapheneOS @Hyolobrika @condret@shitposter.world
Yep, just confirming the Lineage hotspot over VPN feature is extremely leaky and leaks on any state change.
It is noted in the DivestOS documentation, but I've considered removing the feature entirely.
A feature that's meant to hide your actual IP, location, etc. from a service is a privacy feature. The LineageOS implementation of this is very leaky, not just in rare edge cases, and it also groups together traffic in a way that doesn't fit the standard Android privacy model. Android already uses an entirely per-profile VPN configuration and sending entirely separate devices through the Owner VPN goes very far against that system. It's not what we want for this.
It's also very high overhead and essentially prevents the device from sleeping since it entirely loses the hardware offload support, but that would still be the case with a better implementation of the feature meeting our standards. It's an inherent drawback of the approach but we'd be fine with that for a feature which fits into the standard VPN privacy model properly and doesn't introduce new leaks.
We're putting a LOT of resources into fixing the remaining leaks in Android's VPN lockdown mode and we aren't going to add things both making it worse and also heavily interfering with our efforts to prevent leaks. It goes against the purpose of the project and what we're trying to do. If people want to add badly implemented features in their own builds they're welcome to do that. Expecting that we would add anything like that to official GrapheneOS is incredibly strange.
The LineageOS implementation regularly frequently sends the packets without the VPN during network changes, etc. That's what we mean by leaks. It doesn't prevent the packets from not going through the VPN when VPN lockdown is enabled.
Android has some flaws in the VPN lockdown feature for blocking leaks which we're working on resolving but it does successfully block all the regular outbound traffic from leaking.
The issues we've found are edge case DNS leaks which we know how to solve but certain VPN apps aren't compatible and multicast packet leaks which we also know how to solve but our implementation had to be temporarily reverted while we resolve some IPv6 and app compatibility issues.
We're focused on closing all these leaks and definitely aren't going to merge anything which adds bigger forms of leaks.
It's better to run a VPN on the tethered device itself for 2 reasons:
1) they'll get a separate exit IP instead of being tied together
2) it avoids the leaky implementation of tethered VPN support
Both 1) and 2) could be avoided by a better implementation. However, we don't really see a way to solve 1) while being compatible with existing VPN apps.
Tor has built-in support for stream isolation to establish separate routes for some connections. Similarly, with other VPNs, you can open separate routes. The proper way to handle tethered devices would for each to have stream isolation / separate routes. The issue is VPN apps don't provide this in any generic way, it'd have to be part of built-in support for Tor or WireGuard in the OS, which would require making that and doing it properly which is difficult.
We care a lot about doing things properly and avoiding introducing any new privacy/security issues along with focusing on solving existing issues before adding new things. That's just the way we run the project. It has nothing to do with us not wanting people to be able to force tethered devices through a VPN connection.
It often takes us a long time to add a feature available elsewhere because our standards are higher and we aren't going to include half-baked stuff.
@divested @GrapheneOS @Hyolobrika What do you mean by leaky ? DNS requests or ?
@GrapheneOS @Hyolobrika @condret@shitposter.world Why did you delete the issue ? https://github.com/GrapheneOS/os-issue-tracker/issues/30
You want more people to contribute, but then you do things like this.
@cube @Hyolobrika The proposal there isn't something we're going to implement. It needs to be done another way after other VPN features are added.
@condret @Hyolobrika The problems are OS issues which VPN apps are making really hard for us to fix despite knowing how to do it because a few apps like DuckDuckGo "App Tracking Protection" and ProtonVPN have weird incompatibilities with the leak blocking we haven't figured out yet. We're still going to ship it but we may have to special case a couple apps to not have it fully enforced.
@GrapheneOS @Hyolobrika I get it, but you shouldn't delete the issue. Just close it.
@divested @GrapheneOS @Hyolobrika But some traffic might pass through the VPN, right?
@cube
Yes, it does work, but all hotspot traffic will bypass the VPN during state changes of the network (eg. Cell to WiFi) or on VPN switches (eg. Location/exit change), even with the kill switch enabled.
And again as mentioned above by GrapheneOS, you lose circuit isolation when sharing a VPN like this.
@divested @GrapheneOS @Hyolobrika does it also bypass the VPN if the VPN has a built-in killswitch like Mullvad?
@cube
> but you shouldn't delete the issue. Just close it
For your own sanity. So you don't get other people filing the same issue and have to explain it all again.
Deleting issues is the nuclear option for when people use filing an issue as a channel for abuse. Closing issues as 'won't fix' is better for you and people using your software and trying to help.
@strypey @cube @Hyolobrika The issue was being used for abuse and was therefore deleted. There are a bunch of duplicates filed in the tracker regardless.
@GrapheneOS
> The issue was being used for abuse and was therefore deleted
In a way that couldn't be fixed just by deleting only the offending comments?
> There are a bunch of duplicates filed in the tracker regardless
Noobs gon' noob. But some of us know to search for closed issues before filing a new one.