← Back to context

Comment by alkonaut

13 hours ago

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.