From the latest GrapheneOS release notes (grapheneos.org/releases#2020.):
> disable RFC 7217 support (stable link-local IPv6 privacy addresses) and stick to link-local IP addresses based on the (random) MAC addresses
The Linux implementation of privacy extensions is some nasty stuff.
Conversation
Ideally the Linux kernel would do something like a keyed hash of the MAC address with a random secret. Not how either stable or regular privacy addresses work. It actually *causes* privacy issues when using full MAC randomization. Love when privacy features make things worse!
1
1
3
We have more work to do in this area. The stable privacy address feature leads to reusing link-local addresses across different networks. The implementation makes no sense to me. It's strictly worse than always using link-local addresess based on MAC address. What's the point?
1
2
MAC address is available on the local network. If it's randomized, which it is by default in AOSP (persistent per-network random MAC) and GrapheneOS (stateless by default) then it just makes things worse. If there's no MAC randomization, it doesn't make things any better...
1
1
For public addresses, privacy addresses (regular or stable) are better than using a non-random MAC address. I think the way it's done is wrong though. If it did hmac(secret, mac_address), it wouldn't hurt. Instead it uses the secret entirely separately, screwing up privacy.
Replying to
Not really sure what to do about it yet. Going to try to figure out a fix for the next release. As mentioned in earlier threads, there are deeper issues in the Linux kernel TCP/IP stack allowing users to be fingerprinted across networks until they reboot. It's hard to solve this.
2
2
We don't want to change things in a way that the device is clearly identifiable as a GrapheneOS device.
On that note, also need to fix github.com/GrapheneOS/os_, but that's only an issue when not using a VPN and when going out of the way to disable GrapheneOS-related connections.
1
1
4
That issue seems to be because the standard network time toggle was primarily based around obtaining it from the mobile network where extra connections aren't required. Still, SNTP is supported upstream and the way it works doesn't make very much sense with that either...
1