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.

                                                  a month later

                                                  I found a pretty solid solution with the GL.iNet Mudi V2 mobile router. It will function as a hot spot and route all traffic through Mullvad (or other VPN providers). There are many more features and a hidden way to even change the IMEI of the device (but that's illegal in many countries).

                                                  It coats extra money and won't help much with the privacy drawbacks of using SIM cards in general (and you need very good OPSEC if you even want to make use of the IMEI feature). But as a mobile VPN router it's very sufficient for my use case, and it won't drain the phone battery or overheat the phone transceivers.

                                                  I'm not an expert in all of this, so before you rush out and buy such a device, I advise waiting for some experts to chime in and verify/falsify my statements.

                                                    Good thread. I was also caught by surprise in the following scenario.

                                                    I have a secondary Work profile where Wireguard app is running with Always-on VPN and Block connections without VPN toggles enabled in the system settings. I use this profile to access work related stuff on my phone when in need. I was abroad and away from WiFi, so the only internet connection came from the eSim. I needed to submit some code and I did not want to do that on my phone, so I thought that for the first time I will just use my phone as a Hotspot while being logged in on the Work profile and connect my laptop to it. I was surprised to find that once connected my laptop was able to reach the internet but it was bypassing the VPN completely. I thought I misconfigured the Hotspost somehow, but there were no settings regarding this. I double checked the Wireguard app settings, there were no excluded apps or services there as well.

                                                    I would argue that in the context described above such leaky VPN behavior is unexpected. Do I understand correctly from this discussion that this is something Wireguard app developers have missed in their implementation?