Quoting Taiidan@??? (Taiidan@???):

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