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

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

From: Greg Norcie <gnorcie@cdt.org>
Date: Sun, 15 Nov 2015 10:14:19 -0500
Message-ID: <CAMJgV7ZdUHJbet8XRhDw9XfGSuF9bJNT0KAoMf5ms1jm20bHEw@mail.gmail.com>
To: adelespinasse@gmail.com
Cc: "public-privacy (W3C mailing list)" <public-privacy@w3.org>, Joe Hall <joe@cdt.org>
That is a good idea.

But how do we separate out say, opting into a social network making noise
to tell me I have an instant message, from a social network making a noise
so they can engage in cross device tracking?

I can live without sound on say, Facebook, but it'll be harder on sites
like Youtube or Pandora.


On Fri, Nov 13, 2015 at 6:12 PM, Alan deLespinasse <adelespinasse@gmail.com>

> 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


*Greg Norcie (norcie@cdt.org <norcie@cdt.org>)*

*Staff Technologist*
*Center for Democracy & Technology*
1634 Eye St NW Suite 1100
Washington DC 20006
(p) 202-637-9800
PGP: http://norcie.com/pgp.txt


Received on Sunday, 15 November 2015 15:15:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:49:31 UTC