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.
Conversation
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.
2
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
If you disable MAC randomization, it uses the hardware MAC and a stable privacy address for the link-local IP address. Public addresses always work the same way: ephemeral rotating privacy addresses.
GrapheneOS adds ephemeral MAC rand and uses that as the default mode instead.
1
1
We still have both of their standard modes (per-network randomization, device MAC) but we add a 3rd mode.
The problem we need to fix is that when you move across networks, the Linux kernel doesn't start over with fresh public privacy addresses. Keeps counting down same timers.
They should have worked around this but I guess they somehow didn't notice it. You wouldn't notice if your local network has IPv6 but you don't have IPv6 internet access, so maybe the people working on these things weren't testing on networks with IPv6 internet access. *shrug*
Yes, that's (flawed) RFC4941 behaviour. However, of the top of my head, the patch I did for the Linux kernel should have taken care of that: patchwork.ozlabs.org/project/netdev
1
2
This probably does fix most of this issue but they don't backport these kinds of changes to kernel.org LTS releases. Android kernel LTS branches include all of the kernel.org LTS patches and a substantial amount of additional changes, but not this one.
2
1
Show replies

