W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2015

Re: Tracking with ultrasound beacons. Web Audio API privacy considerations need updating?

From: Alan deLespinasse <adelespinasse@gmail.com>
Date: Fri, 13 Nov 2015 18:12:44 -0500
Message-ID: <CAMuhF-+g-FiO0wvCq6ED=-53QYJmCWy4gBrRYGciAFUEn0Qt5Q@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: Joseph Lorenzo Hall <joe@cdt.org>, "Lukasz Olejnik (W3C)" <lukasz.w3c@gmail.com>, "public-privacy (W3C mailing list)" <public-privacy@w3.org>, "public-audio@w3.org" <public-audio@w3.org>
Personally, I think it would be great if browsers (by default) prevented
pages from making sound without the user's explicit permission. Now that I
think about it, I'm surprised I haven't seen this already. Is it an option
that can be enabled in some browsers?

Of course it should be possible to give permission to a given domain to
make sound "from now on", so you don't have to give permission every time
you go to Spotify or something. And there could be a global setting to
allow sound for all sites, without asking. Pretty much like camera and
microphone access is handled by most browsers.

None of this sounds like an Audio API issue, though. More of a policy
decision that could be left to browser developers and/or users.

Also, note that the Web Audio API is not the only way to make sound in a
web page.

I really DON'T like the idea of "filtering out inaudible frequencies". One
person's inaudible is another person's difference between high-quality and
low-quality sound. (I'd be fine with banning all frequencies above ~20kHz,
but (a) that would be fought by the "192kHz is better" placebo-hearers, and
(b) anyone trying to do illicit tracking is more likely to use frequencies
that most consumer hardware can handle.)

I wonder if this kind of threat could be reduced by having some kind of
cross-domain restrictions. I'm speculating recklessly and vaguely here. If
the tracking-sound-emitter is likely to be part of an ad, which is likely
to be loaded into an iframe, maybe it would help for iframes to have a
separate sandbox permission for allowing audio. That way, at least, if I'm
developing an ad-supported site, I don't have to worry about ad networks
sneaking an ultrasonic tracker onto my site.


On Fri, Nov 13, 2015 at 5:00 PM, Robert O'Callahan <robert@ocallahan.org>
wrote:

> On Fri, Nov 13, 2015 at 10:29 AM, Joseph Lorenzo Hall <joe@cdt.org> wrote:
>
>> In some senses, platforms can help. E.g., just like there are small
>> indicators present when an app is accessing location or the microphone to
>> give users notice that something is using those resources, maybe a sound
>> icon could be used? Chrome I think does this with tabs so that you can
>> quickly identify which of dozens of tabs is the one playing annoying audio.
>>
>
> Firefox does this too.
>
> Since this attack works for native apps as well, it's probably best
> blocked by filtering out inaudible frequencies at the platform level.
>
> Also I imagine that if this gets used much in the wild, the scripts
> involved will be added the blacklist used by Firefox's tracking protection.
>
> Rob
> --
> lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
> toD
> selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
> rdsme,aoreseoouoto
> o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
> lurpr
> .a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
> esn
>
Received on Friday, 13 November 2015 23:13:13 UTC

This archive was generated by hypermail 2.3.1 : Friday, 18 December 2015 09:00:35 UTC