It's the browser that introduced many of these APIs in the first place.
That should answer the question.
(If you ask me if a browser should report how many cores the machine has, including physical and logical ones, I would answer never, every time. But not everyone thinks that way. https://developer.mozilla.org/en-US/docs/Web/API/Navigator/h...)
Because it's known that interrupting the user-intent with a unrelated consent-popup doesn't help.
Older people may remember that this was the approach of Java J2ME, where you couldn't provide a fluent user-experience as the user first had to answer huge popups about individual API-permissions with "Always Allow", "Allow now" etc.
You go to Facebook to see your cute nephew make spit bubbles. Do you care that they access your camera and canvas? What is a canvas? And sure access my camera, I want to upload photos!
It's fundamentally broken. They've studied the dark patterns, not to avoid them but to implement them best.
If it's a site I trust, and I think it genuinely needs audio, I give it audio. If someone doesn't understand and just does allow all, they never see it again either (and their ads are suspiciously well targeted).
We already have these consent popups for camera and microphone. Reading back bytes from an audio buffer seems like such a rare thing to do that it hopefully just stops happening.
We do this to check whether the browser is what it claims to be, not to track who you are. Similarly, font rendering, floating-point math results, WebGL renderer strings, and whether built-in functions are patched is all much harder to fake. These considerations determine how hard the proof-of-work puzzle should be, and site owners can see it as a risk score. We don't do cookies or browser storage, IPs aren't stored, and nothing gets used to recognize you on another site or on a later visit. The biggest players in automated traffic prevention can't (and usually don't) say this much, because of conflicts of interest between automated bot detection and their other products (e.g. ad sales and IP-profiling).
Your example is really fair though. I chatted with our engineers, prompted by this thread, and we found nothing in our detection that currently uses the audio hashes we collect, so we've started talking about removing the collection.
For example, on multiple instances, my spouse declined "location permissions" an app designed to work with a piece of Bluetooth-connected hardware, and would blame the hardware as being crappy.
"This smart lock app doesn't work."
"You need to enable this permission."
"Why do I need to give the smart lock app location permissions?"
It's not obvious to people that "Bluetooth can be used sneakily by big-enough companies as a makeshift GPS" even if the app needing Bluetooth access doesn't actually need a GPS location.
We should go further. A web-site with mostly static content should not use user-side scripting (Javascript) at all, it's unnecessary for it. It should be required only in rare cases where a site is basically an application and require manually turning it on each time such application is opened.
Then sites that want to track will just add some JS. Seems unlikely to help.
If such client-side behavior counts as “basically an application,” then “applications” is a larger set than seems useful.
If you don't care about your site being static then you can track it server side, but that has big implications for his you can just your site. Sticking a little flag in localStorage really is the best solution, if you can get past ideological purity.
I agree with you but really from a point of privacy and what/how data is allowed to be mined, shared, sold, etc. The implications to the business/ad industry are second order effects that are just collateral damage.
Simple answer: The makers of 3 largest browsers by market share (collectively 90%+) are buddies with the people who want to fingerprint you. Only the 4th largest gives a shit.
Last I checked it's because it was generally considered that preventing fingerprinting is practically impossible anyway. It's not like you need a lot of entropy for fingerprinting, and the web API surface is enormous. To actually stop fingerprinting you'd need to make your web browser more or less useless.