Proposal for Anti-Keystroke Fingerprinting at the Display Server Level

bancfc at bancfc at
Fri Mar 25 14:38:39 UTC 2016

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 

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).

More information about the wayland-devel mailing list