Open no-usernames-left opened 7 months ago
GrapheneOS our own approach of using a per-connection random MAC by default along with using fresh DHCP state for each network connnection. We recommend leaving this setting at the default value. Filtering based on MAC address is pure security theater and you should avoid doing that on your networks.
The per-network random MAC setting is the standard Android approach which we kept in case you ever have to use a network where you need to register with a specific MAC address. It uses the standard approach to this which calculates a per-network value from a random value. Please read this documentation:
https://source.android.com/docs/core/connect/wifi-mac-randomization-behavior#persistent
You can make it less persistent via Android's standard developer mode toggle for non-persistent per-network random MAC which will use a fresh value after DHCP state expires. We recommend using our per-connection random MAC approach instead.
GrapheneOS our own approach of using a per-connection random MAC by default along with using fresh DHCP state for each network connnection. We recommend leaving this setting at the default value.
Hi Daniel,
I appreciate this, and I almost always do, but on networks with a captive portal it causes me to have to reauthenticate (which also breaks my always-on VPN until I do) every time the device deassociates from the Wi-Fi, which is obnoxious.
Once I'm done on that network, I would like to be able to Forget
it and know that next time I join it in per-network MAC mode it will be a fresh MAC; as it stands I cannot rid myself of the MAC no matter what I do while keeping the MAC the same across associations.
This is a bug and should be fixed; simply randomize the MAC once and store it along with the rest of the data, instead of apparently taking the output of some deterministic hash of the ESSID or whatever it's doing today.
I appreciate this, and I almost always do, but on networks with a captive portal it causes me to have to reauthenticate (which also breaks my always-on VPN until I do) every time the device deassociates from the Wi-Fi, which is obnoxious.
The connectivity checks will detect the captive portal and trigger a prompt for handling it, which bypasses the VPN. This is the main purpose of the connectivity checks. Did you disable them?
This is a bug and should be fixed; simply randomize the MAC once and store it along with the rest of the data, instead of apparently taking the output of some deterministic hash of the ESSID or whatever it's doing today.
It uses a keyed hash with a random key. The random keys are kept persistently and used across networks. It's the officially documented behavior of Android's standard MAC randomization so it cannot be considered a bug. We don't change anything about how the standard randomization works but rather we add our own per-connection MAC randomization and modify DHCP to avoid leaking that it's the same device as before by clearing the state for each connection.
You're making a feature request for a new GrapheneOS specific randomization mode in between our per-connection randomization and their persistent per-network randomization. We don't like the approach of either their persistent or non-persistent randomization but we can't change how that works without breaking it for everyone with it set up already. We'd need to add our own approach to per-network randomization, and we could use the new mode by default for new networks. That's a feature request, not a bug report.
You could use their non-persistent per-network MAC randomization mode if you don't have any networks where you want a long term persistent MAC address but rather you want a mix of per-connection MAC addresses and short term persistent per-network MAC addresses. In non-persistent mode, it should cycle after you forget the network.
The connectivity checks will detect the captive portal and trigger a prompt for handling it, which bypasses the VPN. This is the main purpose of the connectivity checks. Did you disable them?
No. As I said, I have to reauthenticate, and in the meantime while I have not been paying attention to my device's display my connection has died, important notifications have not been received, etc.
You could use their non-persistent per-network MAC randomization mode if you don't have any networks where you want a long term persistent MAC address but rather you want a mix of per-connection MAC addresses and short term persistent per-network MAC addresses. In non-persistent mode, it should cycle after you forget the network.
What do you mean by this?
Read the linked section on the standard Android persistent and non-persistent MAC randomization modes. You can turn on their experimental non-persistent mode if you want, which doesn't save them beyond DHCP lease expiry, 24h or forgetting the network.
If we were happy with stock Android, none of this would exist.
If I hit Forget
, I would like every aspect of the network to be forgotten, including the per-network "randomized" MAC.
I have elucidated the value to users, especially those temporarily using networks with a captive portal, and those users should not need to resort to developer hacks.
Please reopen as a feature request.
If we were happy with stock Android, none of this would exist.
If I hit
Forget
, I would like every aspect of the network to be forgotten, including the per-network "randomized" MAC.I have elucidated the value to users, especially those temporarily using networks with a captive portal, and those users should not need to resort to developer hacks.
Please reopen as a feature request.
There is nothing wrong with this toggle under developer options and has nothing to do with "hacks" it's just an option that's offered for those few that need a different approach then what is currently offered.
I personally use "turn of absolute volume" for example because I can't stand the default approach.
Maybe grapheneos will add a different option, maybe not but in the mean time the suggestion to use this toggle is a great option to try.
There is nothing wrong with this toggle under developer options and has nothing to do with "hacks" it's just an option that's offered for those few that need a different approach then what is currently offered.
The approach it uses doesn't make much sense. It changes MAC when DHCP lease expires and when the network is forgotten, which makes sense, but changing it on every reboot too doesn't make much sense.
Privacy
setting toUse per-network randomized MAC
(which will also disconnect you)Forget
Privacy
setting toUse per-network randomized MAC
(which will also disconnect you)Expectation: the MAC is different than before
Reality: the MAC is the same as before, even across a
Forget
This is not "random" for any commonly-accepted definition of the term "random".