Quoting taii...@gmx.com (taii...@gmx.com): > Yeah just like I have said before this is the only logical reason as > to why browser fingerprinting is still so easy to perform even after > years of the vendors knowing about it.
Like many questions of interest, that is actually complicated. Behind the scenes, Web browsers cheerfully answer quite a lot of queries about themselves, and pretty much all of them have legitimate uses. Don't want your browser to respond to queries for multi-monitor support, internal hashtable implementation, WebRTC implementation, match constants, accessibility support, presence or not of a camera and its type, DRM support or not, accerometer support or not, virtual keyboard support or not, gesture support or not, pixel density, video and audio codecs supported, nature of the audio stack, extensions/plugins available..., the user is likely to have a lousy, frustrating experience. All of those things can be induced to lie or to withhold informataion, but there would be a serious price to doing so, and frankly only an advanced user of Web browsers who knows a lot more about the innards of Web browsers than I do could really stay on top of managing browser state on a need-to-know basis. And of course, that leaves out nearly all users of the software. Some of the things I have traditionally done for policy reasons, notably setting the User-Agent string to 'Stop fucking obsessing over user-agent and code to W3C standards already' had the accidental effect of making my browser _more_ fingerprintable. It's actually an incredibly difficult problem. Read more (including pragmatic suggestions) at https://panopticlick.eff.org/about . _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
