New Site Checks Your Browser's Fingerprint
"Does your web browser have a unique fingerprint? If so your web browser could be tracked across websites without techniques such as tracking cookies..." warns a new site created by the University of Adelaide and ACEMS, adding "the anonymization aspects of services such as Tor or VPNs could be negated if sites you visit track you using your browser fingerprint." AnonymousCube contacted Slashdot about their free browser fingerprinting test suite:
On the site you can see what data can be used to track you and how unique your fingerprint is. The site includes new tests, such as detecting software such as Privacy Badger, via how social media buttons are disabled, and CSS only (no JavaScript or flash) tests to get screen size and installed fonts.
If you're serious about privacy, you might want to test the uniqueness of your browser's fingerprint.
If you're serious about privacy, you might want to test the uniqueness of your browser's fingerprint.
you've known that browser fingerprinting is real and beimg used for years.
https://panopticlick.eff.org/
systemd is Roko's Basilisk.
It is a fork of https://panopticlick.eff.org/ and about the same thing with a few more tests. And I am unique on both.
"It is not just a refer. How about if it queries what fonts you support? Any of them not standard? How about media support? What java and flash are you on? What is your screen resolution? Browser window size if not full screen? There is a lot to catch..."
HTTP is request based. The client asks for what it needs: the server does not push out what it thinks the client needs.
Font support: the server has no need to know about my fonts. The CSS should suggest the preferred fonts, but if I don't have their preferred font installed then my browser will substitute. The server never needs to know this.
Media: my browser will ask for the media it wants to display. If it can't display media it won't ask for it. If it asks for something complex, like a movie file (for example) and the file downloads and then it is unable to handle the file, then surely this should have been managed my correctly identifying the MIME type of the file. The browser can then terminate the download, knowing that it won't be able to play it. Yes, I appreciate codecs make this trickier than it has to be: HTML5 should have fixed this. Comments?
Screen Resolution: none of the server's business.
Window Size: again, none of the server's business. If your website is so crappy that it must autosize in some stupid [yes, there are **few** caveats] way then this should be done using local JavaScript.
So, provided I haven't pissed everyone off: assuming all clients implement the HTTP standards correctly and uniformly, please remind me why the server needs to know anything about the client?