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

cheers

chaals

> 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