Re: Audio & security

What worries me is not the microphone (which already requires the user's
authorization, as you say), but the speakers, and outputting of inaudible
audio. (Not really related to your blog post)

Possible threats I can think of:
* A site exposing the physical presence of its users to other users in
their vicinity.
* Malicious site driving dogs/other animals insane (a little out there, I
know)

Again, maybe I'm being paranoid, and this is a non-issue.
 On Aug 13, 2013 8:06 PM, "Boris Smus" <boris@smus.com> wrote:

> Hi Yoav & list:
>
> The approach in the blog post already requires the live audio input
> feature of the Web Audio API. This feature will prompt an infobar to enable
> (unless previously enabled and persisted on an https site). When a
> "SonicSocket" is open, all that means is that the microphone is listening.
> Therefore the browser will display the same warning/indicator that is shown
> when the microphone is on.
>
> I think both of these are clear signals and that no additional security is
> needed here.
> - B
>
>
> On Fri, Aug 9, 2013 at 2:31 PM, Yoav Weiss <yoav@yoav.ws> wrote:
>
>> Boris Smus wrote an excellent blog post about the use of WebAudio for
>> short range data transmission using inaudible audio (
>> http://smus.com/ultrasonic-networking/).
>>
>> That got me thinking regarding the security implications of the Web Audio
>> API & inaudible audio in general.
>> I'm not really sure if & how this can be exploited. XSS can use it to
>> send data to the user's proximity, but it can already send it to anywhere
>> in the world today.
>> It might more likely be used to detect other users in the vicinity &
>> communicate with them, which can be a feature but can also be a security
>> issue if the user is unaware.
>>
>> Is this use of inaudible audio worth considering in term of its security?
>> Is it something that we want to require the user's permission for? Maybe a
>> warning/indicator? Or am I just being paranoid?
>>
>> Yoav
>>
>>
>>
>