W3C home > Mailing lists > Public > public-webappsec@w3.org > August 2013

Re: Audio & security

From: Boris Smus <boris@smus.com>
Date: Tue, 13 Aug 2013 11:05:45 -0700
Message-ID: <CAPMopsvTD7oJAe43BpoX2HAV0VwNMYaFsyvVFBwKT3Hd8xj5Aw@mail.gmail.com>
To: Yoav Weiss <yoav@yoav.ws>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
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
>
>
>
Received on Tuesday, 13 August 2013 18:06:35 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:02 UTC