Conversation

Replying to

One IPv6 issue has been reported upstream and after resolving an initial misunderstanding they seem to be on the same page about it. It would be best if these kinds of things were resolved upstream. It takes them a long time to deal with it though. Maybe Android 12 at least.

1

1

20

You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more

Replying to

and

They handle the link-local addresses in a reasonable way: uses MAC address when there's a random MAC address, otherwise a stable privacy address. They were previously screwing up MAC address randomization by always using stable link-local privacy addresses on newer Linux kernels.

2

1

Replying to

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.

2

2

Replying to

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

Replying to

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

Replying to

and

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

Replying to

and

If you want to avoid correlation, why do you use stable addresses in the first place? Why not RFC8981 addressess only?

1

Replying to

FWIW, we explicitly removed the requirement to configure stable addresses with that in mind ;-)

1

Replying to

and

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.

9:13 AM · May 23, 2021Twitter Web App

Replying to

and

Do you really want/need a stable address on an Android phone?

1

Replying to

and

If you explicitly disable MAC randomization their assumption is that you do want a stable IP address. It's not at all normal to disable MAC randomization. Their default mode is persistent per-network randomization based on a keyed hash of the SSID so that MAC doesn't change.

2

Show replies

Replying to

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

Replying to

The broken part is the public privacy address feature in the Linux kernel. We should have a fix for our next release though. Have known about it for quite some time but we needed to figure out the best way of working around it. There are other non-address-related issues too.