Share VPN with hotspot ?

Skyway

Is there a way to share VPN with hotspot devices ?
This is available on my pixel running divest os but I don't see it on grapheneos .

matchboxbananasynergy

No. The way this is implemented elsewhere doesn't make a lot of sense.

We've considered a similar feature, but there is currently no implementation that would make sense to include.

In the vast majority of cases, it's always going to be more private for the "guest" devices to have their own VPNs, same as each profile on your own device has its own VPN slot.

Skyway

matchboxbananasynergy ah OK , my tethered device can't easily add a VPN . And using one VPN might mitigate hotspot detection/ throttling from mobile provider ?

de0u

Skyway My tethered device can't easily add a VPN . And using one VPN might mitigate hotspot detection/ throttling from mobile provider ?

These are valid issues. The approach taken by some other AOSP variants has been considered (multiple times) by the GrapheneOS developers and they do not plan to go that route. It is possible that Google will decide to address these issues upstream (in AOSP). It is also possible that a member of the community might work out a technically-sound solution and submit it for consideration by the GrapheneOS developers. But personally I would be pretty surprised if GrapheneOS implemented VPN support for hotspot clients any time soon.

DownWithBaradDur

matchboxbananasynergy sorry, respectfully. I really appreciate your work but it's wrong to not add a feature because you couldn't think of how to use it at an instant.
Sharing VPN allows the possibility of relay configurations.
What if a device using the hotspot uses a VPN service and the Graphene device sharing the hotspot uses Orbot?
You could make the request go through tor and have the exit node be a VPN server, henceforth avoiding tor censorship from the website while using Tor for more security.

I'd like to respectfully request this feature to be added. I was actually surprised to find it didn't have it.

DownWithBaradDur

matchboxbananasynergy you've already been given great other reasons to add the feature at https://discuss.grapheneos.org/d/2916-tether-thru-vpn.

the network operator can no longer see that the GOS user is running a hotspot. (some providers still charge extra)

not all devices can be operated as a VPN client and therefore currently expose the IP that is directly linked to the GOS user. (most common reason this is needed)

People with whom you share the hotspot do not necessarily have a VPN or care about your privacy.

Any chance we could see the feature added please? I want to use devices that don't have VPN clients.

de0u

DownWithBaradDur Any chance we could see the feature added please?

An issue was created a long time ago, and, after some time, deleted by the developers.

An official source has recently indicated (matchboxbananasynergy) that there are no plans to implement this, and beyond that there is a disbelief in the desirability.

Re-stating reasons why the feature might be desirable, that were previously stated and considered, can be done, but it seems unlikely to change the outcome compared to other possible actions.

DownWithBaradDur I want to use devices that don't have VPN clients.

If a sufficient quantity of people also want that, somebody could implement it for GrapheneOS and submit a pull request. If it were reviewed favorably (perhaps after changes were suggested and made), it might be incorporated. Or, if there were an implementation and it had been rejected and there were a community of people who very much wanted the feature, it would be possible for that community to fork GrapheneOS.

Quotesquestioner

de0u it works on my galaxy s9 (stock googleandroid) with that method i could use my PlayStation with a vpn. I think the demand for this function must be pretty high. By the way it would be. X tr E mly happy if there where a possability to vote for functions in grapheneOS. You could build it in the new jnformation app. Would be great.

Ps: why the current forms of that functions are not good can you give a quick little inside?

GrapheneOS

DownWithBaradDur You can chain VPNs without this feature.

GrapheneOS

Quotesquestioner VPNs are per-profile for privacy reasons. Sharing the same exit IP address across multiple of your devices as opposite to having it finer-grained than a whole device isn't desirable. It ties that traffic together. It's better for each to have their own VPN. Phones are not great routers in the first place but doing this VPN routing completely loses the hardware acceleration and forces the phone to be awake to route every packet from each client. It seems very unlikely this would ever be added to AOSP since it's quite messy.

Sharing the same tunnel between the Owner user and other devices is very arbitrary. Why specifically the Owner user VPN getting used across multiple separate devices? Shouldn't the feature be designed to have a dedicated VPN route for each device or at least the overall connected clients? That doesn't fit very cleanly into the standard app-based model. It requires having some kind of profile feature for setting up a VPN for the hotspot clients. Why would GrapheneOS system updates and other system traffic along with all your apps there be tied to other devices instead of separate? Profiles are much more closely tied together than separate devices but yet have an entirely separate VPN setup for each one. The approach of routing several other connected devices through Owner's VPN doesn't fit into the existing privacy design.

When Wi-Fi hotspot is active, the device providing it and devices using it can be trivially tracked by the MAC addresses. Access points are meant to be static in the Wi-Fi privacy model. If you carry around an active access point with you or remain connected to the same access point while travelling around, you've enabled trivial tracking. Bluetooth Low Energy (BLE) has a stronger privacy approach as option features which are able to defeat a lot of tracking for devices being carried around paired with each other, although it consistently has flaws needing corrections.

Quotesquestioner

GrapheneOS that all makes sence and raise mire questions.
Is a vpn acces point in the home network than also a bad idea because of the same reasons? Should every device have its own vpn suscription account then?
Or are you just talking for the android/graphene environment?
Why are phones no good routers in general?
I thaught of getting a second grapheneos device to use it just as a vpn/tor router.

And if i am carrying around an acces point lets say for now a simcard mobile router, and i use it just for one graphene device i am enabling trivial tracking? Which anthety vould track what exactly how?
Or does this part of your answer just relate to a phone as a router? If so what if the only purpose is to work as a router would that change what you say about it enables trivial tracking?
The last question is the most importand one

de0u

Quotesquestioner Why are phones no good routers in general?
I thaught of getting a second grapheneos device to use it just as a vpn/tor router.

Phone hardware is not designed to be run flat-out for years on end. Both the Wi-Fi transceiver and the cellular transceiver are heat sources, and packet disassembly/reassembly is also a heat source, so cooking the battery is plausible. Pretty much all routers are larger and have more air inside, and more metal, than phones, and none of that is by accident.

Using a phone as a router is a natural idea since there are so many of them kicking around, and it can be done, but it doesn't mean that a phone is a good router. In the GrapheneOS space, it's unclear that a phone that is still under support will cost less than a dedicated SOHO router.

de0u

Quotesquestioner By the way it would be. X tr E mly happy if there where a possability to vote for functions in grapheneOS. You could build it in the new jnformation app. Would be great.

How to prevent vote spamming by malicious parties, or even just parties who are very enthusiastic about some specific feature and think a couple extra votes for a super-important feature wouldn't hurt?

GrapheneOS

Quotesquestioner Every device should really have their own tunnel. You should want finer-grained than one tunnel per-device as Android profiles provide. It doesn't have to be a separate subscription if you're not trying to mask that they're tied together from the VPN provider themselves.

I thaught of getting a second grapheneos device to use it just as a vpn/tor router.

It's more secure than most options but it's not very good at actually acting as a router. If you're using Tor, wouldn't you at least want stream isolation for each device? Why tie it all together? Doing it per-connection is much higher overhead than per-device / per-profile.

And if i am carrying around an acces point lets say for now a simcard mobile router, and i use it just for one graphene device i am enabling trivial tracking? Which anthety vould track what exactly how?

You can be tracked by the client and access point MAC addresses which remain the same while connected. The AP one is also going to remain the same even if the client cycles it per connection like GrapheneOS.

The cellular modem in the phone is also more secure than almost any external one which probably won't even get basic security patches properly and the one in the phone has good isolation. Phones are expensive so if you goal is cycling the radio hardware identifiers when changing SIMs, it wouldn't be very practical to replace the whole phone. Doesn't mean that a hotspot device is good at doing this though. It's also going to stand out compared to a phone. What's the goal?

GrapheneOS

de0u Routing all the traffic through the OS also massively increases the power usage and heat from it compared to using the hardware offloadl. Using the hardware offload rules out having it go through a VPN at least without special hardware support something like WireGuard directly, but that's odd compared to each client using a VPN themselves and is unlikely to happen.

de0u We could use hardware attestation for this purpose but we don't place much value in root-based hardware attestation as opposed to pinning per-pairing keys which has no use for this. We aren't going to decide our priorities based on votes anyway.

Quotesquestioner

de0u by implementing it in the info app from grapheneos. Mabe making this function tied to the main profile so its not possible to vote from other profiles. That way only graphene users could vote one time per thread. I don't know exactly if this is enough to prevent bad behaviour but mabe a pgp implementation of some how would help. I don't know you are the developer :)

de0u

Quotesquestioner See official answer just above (GrapheneOS).

GrapheneOS

Quotesquestioner It's possible to make it quite difficult to cheat beyond purchasing more devices but it's not actually something we want to do. It would be possible to cheat via leaked attestation keys provisioned to devices which chain up to the Google root and we don't see this as a high security approach. Our Auditor app is mainly based around pinning and the verified boot key fingerprint shown at boot is an important part of setting things up for the initial verification.

Quotesquestioner

GrapheneOS you could give us the strong feelings our opinions matter to you (i know you do but more is always better, at least in this case). That would make the rope between user and developer stronger and that would increase reputation. In the end you don't have to do what is voted for. It could be a tool that is beneficial for both sides. But i think people would love it. I would.

Quotesquestioner

GrapheneOS

GrapheneOS You can be tracked by the client and access point MAC addresses which remain the same while connected

Ain't i am the client in thisnscenario? Or who is it? And the access point mac address is my routers mac adress?
I mean who can track me down?
I think the only one is the isp. Or are there more who could track me down with a mobile accespoint ?