It's difficult dealing with privacy improvements to the Linux kernel which would be apparent on the network. It ends up being counter-productive by identifying the device as running some niche version of the kernel. Some of these things really need to be changed though...
Conversation
Recently ran into tools.ietf.org/html/rfc7217 and spent all night looking into this and playing with it. It's horrible. Going to be pretending that the kernel doesn't have support for it to make sure it's never used. It led to identifying other problems through reading and testing...
1
1
Already want to implement a toggle for choosing between connectivitycheck.grapheneos.org/generate_204 and the standard connectivity / captive portal check URLs. This is not quite the same thing since the kinds of TCP/IP stack changes involved can be fingerprinted even if traffic is routed via a VPN.
Replying to
About tools.ietf.org/html/rfc7217... why would you want to have a long-lived secret using to make a persistent link-local 'private' IP address per-network based on PRF(secret, network details) rather than just basing it on the (random) MAC address which is available locally anyway?
1
1
That works perfectly... if the MAC address is fully random, the IP is fully random. If the MAC address is random per-network, the IP is random per-network. If the device MAC address is used, or a global random MAC, the IP is persistent. Linux also implements the spec BADLY.
4