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.

      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

          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.

              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?

                  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?

                      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.

                            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 :)

                                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.

                                  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.

                                      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 ?

                                          GrapheneOS It's also going to stand out compared to a phone. What's the goal?

                                          So the celltower/its company can see what kind of device is in use?/they can see this is a phone this is a sim router?
                                          At this point it's more of a hobby. I like to learn. I like the progress. I want to know how everything works. And i think if i don't act now, some day it is too late to start. The government gets more cobtrolling every day. I have no time to loose to become a ghost in my digital life. Mabe it will save my life in 10 years. Mabe i can help others to know what they have to to protect themselves.

                                          • de0u replied to this.

                                              Quotesquestioner So the celltower/its company can see what kind of device is in use?/they can see this is a phone this is a sim router?

                                              Generally, yes. Each device has an IMEI, typically assigned by the manufacturer, and which IMEI ranges belong to which model of device is widely known. Devices with spoofed IMEIs likely can be behaviorally fingerprinted.

                                                GrapheneOS 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.

                                                This is only true if you take a very narrow view of its intended use. It is extremely desirable if you consider the most likely use-case, simultaneously running a VPN and firewall app, which, in so many words, may very well be the most requested feature and recurrent topic on this forum. A toggle of sorts that allowed users to share their Owner VPN connection with, at least, a sub-profile would be perfect for this.

                                                That toggle doesn't exist, so it's currently impossible to run the more privacy-respecting VPN apps like Proton, IVPN, or Mullvad simultaneously with something like Blokada or Adguard because both are afforded only a single 'slot'. People now have to either root the device, forfeit one option, or mess around with not the most intuitive hack that allows a firewall app to offer some VPN functionality. The complex but otherwise useful RethinkDNS is commonly recommended for that last option but the app is really a DNS/firewall app first and 'supports VPN' second. The UI is not the most intuitive thing to someone used to the earlier mentioned VPN apps, causing the mental burden of worrying about pressing any button because the wrong one might just bust your VPN. You also forfeit expedient location changes using it and worse, now have to trust them to not have bugs that might subtly break the VPN while they build out their firewall/DNS features. This is a big ask when the VPN compatibility is secondary to their product. If that wasn't bad enough, all of this is off the table if you rely on obfuscation/anti-censorship measures in the full VPN app.

                                                Something similar to the 'Block connections without VPN' or 'local sharing' toggles that exist in the OS and VPN apps makes these problems go away. Things become even more intuitive and seamless with the upcoming Private Space feature in Android where you no longer have to deal with switching profiles.

                                                Another high privacy/anti-censorship use case enabled by this that is increasingly relevant these days is nesting VPNs, explained here. You could have your more privacy-respecting but censored VPN running in the Owner profile, sharing its connection, and the less privacy-respecting but more available VPN in a sub profile or the Private Space without exposing your IP to the nested VPN. This is iCloud Private Relay without being limited to certain countries or the Safari browser.

                                                    I am still in favor of sharing VPN with hotspot . let the end user have the choice to enable it or not. one could make a profile just for sharing vpn if needed, especially in the case where the client can't host a VPN its self .

                                                      Skyway I am still in favor of sharing VPN with hotspot .

                                                      It is still possible for a group of people wanting that to submit code (de0u).

                                                          4 days later

                                                          ignition nested VPN. This is iCloud Private Relay

                                                          Note that, Private Relay is based on new protocols, most of which are being standardized by various working groups at IETF (ex: masque, privacy-pass). These protocols are being developed by some FOSS projects already, and Cloudflare has publicly indicated that they use it for their enterprise VPN offering, iirc.

                                                          Shouldn't need nested VPNs once these new standards go mainstream, which hopefully happens sooner.

                                                            12 days later

                                                            ignition The OS already has a built-in firewall. A VPN app providing both filtering and an actual VPN tunnel is entirely supporting. They can also support chaining connections. None of that requires any changes to the OS and none of it has anything to do with profiles or what profiles are supposed to provide.

                                                            The complex but otherwise useful RethinkDNS is commonly recommended for that last option but the app is really a DNS/firewall app first and 'supports VPN' second. The UI is not the most intuitive thing to someone used to the earlier mentioned VPN apps, causing the mental burden of worrying about pressing any button because the wrong one might just bust your VPN. You also forfeit expedient location changes using it and worse, now have to trust them to not have bugs that might subtly break the VPN while they build out their firewall/DNS features. This is a big ask when the VPN compatibility is secondary to their product. If that wasn't bad enough, all of this is off the table if you rely on obfuscation/anti-censorship measures in the full VPN app.

                                                            This is something you need to take up with app developers. The main issue with nearly all Android VPN apps is that they exist as an Android client for a service rather than trying to make a good Android VPN app. WireGuard's app would be a good place to implement chaining but since it's a WireGuard project app, clearly they're probably not going to add filtering. People would need to fork the app to add that.

                                                              Skyway A leaky implementation or one that's using the Owner profile VPN is never going to be accepted, which are two fatal flaws with the existing LineageOS implementation used elsewhere. A feature which adds major new VPN leaks is never going to be added. Both the leaks for the tethered clients and sending traffic through the Owner profile VPN are unacceptable. That approach will never be accepted and people might as well accept that. It is not how we do things.