Comment by rickdeckard
13 hours ago
> "I still don't understand why the highest entropy APIs aren't gated behind browser consent"
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.
If it isn't an informed decision, it isn't really a decision at all. And the huge majority of people the huge majority of the time do not want to make an informed decision: they want what they came to the site for, news, games, family photos, 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.
Absolutely. I spoke to an ex-Meta guy and his only answer to stuff like this was "actually its good for privacy because they don't want third parties to access your data since its valuable"
So long as it's once per API and site, it seems it doesn't need to be too bad?
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.
It's less rare than you'd hope. Disclosure: I do developer relations at Friendly Captcha, and our widget is one of the scripts that uses generated offline audio (but with no microphone recording) and reads the buffer back on sites that otherwise have no use for audio.
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.
I think "proof of humanity" is going to be an increasingly important thing, but I think we need to forego the age-verification and make some sort of zero-proof/integrity-preserving age/humanity verification.
Also, people not in tech do not generally understand the implication of consent popups.
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.
Your partner isn’t wrong. It’s a crappy product and crappy ecosystem when you have to be hyper precise.