On Thu, Nov 10, 2016 at 08:02:20PM +0100, Lennart Poettering wrote: > Other operating systems, notably security-focussed ones like ChromeOS, > go the other way, and try to remove as many identifiers as possible > that could be used to track users. In fact, at LPC we discussed even > making /etc/machine-id an optional concept in that context, so that > there really would not be any useful local ID that could leak to > external systems. Saying that ChromeOS "tries to removes as many identifiers as possible that could be used to track users" is a joke: the whole purpose of that OS is to track users ;) The only difference is in who does the tracking. > I must say I sympathise with ChromeOS approach there, I think it would > make sense to default to more secure default in this regard, rather > than opening this all up. It certainly is good to protect privacy in some environments, but at the same time, there are various use-cases where being able to easily identify the machine is crucial for usability: soho networks, wifi sharing, any kind of setup where you want to share data in an ad-hoc setting, printing, freeipa, etc. In fact systemd itself follows this kind of logic: LLDP, LLMNR is enabled on "trusted" networks. If I'm in a trusted network, where I can identify the machines anyway, making me jump through hoops like manually checking MAC addresses or comparing IP numbers to guess which machine is which is pointless. And disabling the hostname does not really buy much: anyone with control over the network are likely to be able to identify the machine using MAC address, the DNS queries it performs, and other access patterns. If we resolve https://fedoraproject.org/static/hotspot.txt immediately after connecting, the information that the hostname is "Fedora-XXXXXXXXX" does not change anything. I think we should work on not leaking the hostname in untrusted settings (which effectively means "unless told otherwise"), and not trying to make the machine completely anonymous. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
