Hello all. I've just recently found this chat but have been involved in device fingerprinting for 6+ months now. Me and my team recently did some work on determining whether a mobile device is a real mobile device or an emulator. I would be happy to share my results if anyone is interested. It is not perfect but basically it relies on the number of calculations or speed of canvas rendering. Even on a low quality laptop the laptop running the emulator outperformed many smartphones. Only the most expensive phones (Android) were able to give similar results. If you use a quality desktop with graphics cards, i7, etc it is not comparable.
I wanted to ask if anyone has experience with TCP/IP fingerprinting? I believe ThreatMetrix uses it. From a few days of research I have found you can determine a few things from the data such as OS. I am working on a solution to beat proxies (other than a database of ips).
Hi @Valve, everyone,
I've just finished my research on fingerprinting and I have couple of thoughts to share with you. I believe you may find them an useful contribution. I will simplify the story as it is going to be quite long anyway.
A couple of months ago, I have developed a similar fingerprinting solution and collected many deterministic samples for analysis of fingerprints "usefulness". I was trying to answer the question which features should be fingerprinted in which way to provide the highest entropy, ensure stability, at the same time having on mind an overall execution time and the code length. Here are some thoughts/questions/observations:
1) First of all, what is the point of having fingerprints from "has the user tampered with" family? I see a logical hole here – creating artificial fingerprints out of existing one doesn't increase the diversity but just consumes the code length and execution time. If it's not clear what I mean by artificial, let's make an example: we collect screen.availHeight and screen.height properties as one fingerprint; we create second fingerprint telling availHeight > height; if an user tampered with the setting, the first fingerprint will already make the final fingerprint different from the other, adding additional flag will not improve the uniqueness as this is just a duplicate information (paradoxically, users that are trying to hide their identity by setting some strange values are making themselves easily 'fingerprintable', beauty of this world ;))
2) I believe ad-block detection should be disabled by default, the same way as flash font detection. In some browsers, add-ons are not enabled in private-mode (unless the user does it), therefore the fingerprint is often different while it shouldn't.
3) Concerning execution time, especially when fingerprinting JS fonts using extended list is enabled, the overall time gets quite heavy. I have noticed it affects the user experience in some cases, e.g. some scripts responsible for scrolling are getting starved. I know there is no easy way to solve the issue as we cannot use WebWorkers but at least the problem could be addressed / or the overall execution time decreased. I have implemented a naive solution for my script but I didn't really have time to check if it's making much of difference.