We were disabling that feature downstream but now we no longer need to disable it since they fixed it to be conditional. There are still other issues though. The Linux kernel happily reuses the global privacy address across networks. State isn't always properly flushed for it.
Conversation
It's worse to have privacy addresses enabled right now if you're using MAC randomization than not having them enabled. In theory, they help due to rotation but in practice there are serious issues with them. Some network management tools reset more state and handle it better.
1
1
There are other issues aside from the addresses. It's frustrating digging deeper into it and realizing how screwed up this stuff is in the Linux kernel. Shouldn't need to reboot between connecting to each network to avoid reusing identifiers, 'keys', counters, etc. for things.
2
1
You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more
Agree, and we don't intend to disable privacy addresses, but it's frustrating that a privacy feature is making things worse than not using the feature. Not much point using privacy addresses for link-local addresses though, so the new status quo for that upstream is good.
1
2
If you want to avoid correlation, why do you use stable addresses in the first place? Why not RFC8981 addressess only?
1
FWIW, we explicitly removed the requirement to configure stable addresses with that in mind ;-)
1
Associated MAC randomization is enabled by default in Android. It uses a persistent per-network random MAC address. When MAC randomization is enabled, they use a link-local IP address based on the MAC address. They only use the stable privacy address feature when MAC rand is off.
2
1
GrapheneOS adds an ephemeral MAC randomization option and that's the default for us. It can be changed to per-network MAC randomization or disabling MAC randomization, which are the 2 options in AOSP and the stock OS on Pixels without modifications to them.
2
1
My take is that if you randomize the MAC addresses (*not* on a per-network basis), you probably have no reason for configuring a stable address. -- so you should doing RFC8981-only.
1
Stable privacy addresses are only used by Android when MAC randomization is disabled. The stable privacy address feature otherwise isn't used. The issue with public IPv6 addresses isn't an intentional design choice by Android but rather a Linux kernel design issue.
It reuses those public privacy addresses when stable addresses are explicitly disabled. It's not caused by asking for stable addresses. It's caused by the Linux kernel not offering an alternative unless you go out of the way to flush the state somehow and avoid it reusing them.
1
Yep. Because that's a flaw from RFC4941: the temporary IIDs are only re-cycled on a time-based, as opposed to also re-cycled by e.g. link down/up events or the like...
1
So, if you stay on the same net, for a long period of time, no addresses remain stable? -- my recolection is that Android did RFC4941+RFC7217 of sorts... (i.e., *not* temp-only..)
1
By default, Android uses a persistent random MAC address for each network, a link-local IPv6 address based on the MAC address and an ephemeral public IPv6 address rotating daily for new connections and valid for up to a week per Linux kernel defaults for privacy address rotation.
2
1
Show replies