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