On 2016-03-24 19:49, Jasper St. Pierre wrote:
I think this should be done at the application level. If an application is running, it has many other ways to fingerprint your computer, including listing the files in your homedir, checking cpuid, MAC address, etc.
Many solutions like virtualization and Mandatory Access Controls and eliminate such identifiers. Robust systems are made up of security and privacy conscious decisions in all parts of the stack.
The issue here is that there is an application platform that runs untrusted user code, which has tried hard to get rid of fingerprinting identifiers (however, I believe window size, installed fonts and GPU rendering differences remain the primary fingerprint identifiers at this point for ad networks). The randomness in the event stream should be done in the air-gap between the trusted code and the untrusted code.
Note that many other applications leak this sensitive information and realistically one cannot know about and engage all their developers. Among affected applications is SSH (when used in interactive mode), every other browser out there with the exception of Tor Browser, JS chat clients and who knows what else. This needs to be killed at the system level.
Ad networks have evolved from simple cookies to device fingerprinting (as you point out) and lately to biometric fingerprinting. The latter is their favorite because of it allows them to track people across different devices with great accuracy.
Too many other use cases require completely accurate timing, and I'm not convinced a generic solution for defeating trusted code is a good idea. Perhaps a library can be shared between implementations.
Sure make it optional so gamers don't get upset but please understand that Linux is used in a variety of security sensitive contexts too and people who care about this would benefit. Modern software like Wayland is already written with the assumption of working in hostile computing environments unlike X (for example that's why you don't let an application sniff input events of another).
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
