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: Chaals McCathie Nevile <chaals@yandex-team.ru>
Date: Mon, 30 Nov 2015 12:07:06 +1000
To: norcie@cdt.org, "Alan deLespinasse" <adelespinasse@gmail.com>
Cc: "public-privacy (W3C mailing list)" <public-privacy@w3.org>, "Joe Hall" <joe@cdt.org>
Message-ID: <op.x8wuh4y7s7agh9@widsith.local>
On Tue, 17 Nov 2015 03:31:02 +1000, Alan deLespinasse  
<adelespinasse@gmail.com> wrote:

> 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 this proposal has merit and we should explore it further.

> 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.

Right. But for example blind users *often* want to customise their  
notification signals, and having a set of them could make that process  
easier - and easier to share, so people don't have to do it all themselves.

> 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.

Well, we only increase the settings for increased privacy, in the case  
where the browser doesn't make automated decisions...



> 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
>> /***********************************/

Charles McCathie Nevile - web standards - CTO Office, Yandex
  chaals@yandex-team.ru - - - Find more at http://yandex.com
Received on Monday, 30 November 2015 11:07:40 UTC

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