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

Maybe there should be a set of standard notification sounds that web pages
can play, similarly to how there are standard mouse cursors to choose from.
Browsers could implement their own policies about whether a page should ask
permission before being allowed to play standard notifications, or only
before allowing arbitrary sound-making. If a page is only allowed to play
standard notifications, there would be no risk of ultrasonic tracking.

Not only would this allow increased privacy, it would make it a lot easier
for simple web pages to play notifications sounds. No need to create
samples and download them to the client.

I think a lot of OSes already have something like this. There can be
facilities for "themes" and for user-defined custom notifications. I don't
think it needs to get that fancy, though, for most users.

One potential drawback is having to increase the number of privacy settings
users have to deal with, or having to ask them for permissions more often.


On Sun, Nov 15, 2015 at 10:14 AM, Greg Norcie <gnorcie@cdt.org> wrote:

> 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.
>
> -Greg
>
> On Fri, Nov 13, 2015 at 6:12 PM, Alan deLespinasse <
> adelespinasse@gmail.com> wrote:
>
>> 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
>
> Fingerprint:
> 73DF-6710-520F-83FE-03B5
> 8407-2D0E-ABC3-E1AE-21F1
>
> /***********************************/
>