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

Hi

2015-11-12 21:29 GMT+00:00 Joseph Lorenzo Hall <joe@cdt.org>:

> (I'm not on public-audio, so I don't think my mail will make it there.)
>
> This is something we've been concerned about recently here at CDT.
>
> 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.
>

Good direction. But the icon should not disappear after the audio sound is
finished playing. Those beacons are surely very short sounds.

>
> I do think that permissions to access the speaker are going to be hard to
> justify and more difficult to get any UAs to actually build in. It's just
> too common for something to want to access the speakers. Maybe permissions
> could be triggered for audio that is clearly outside the range of normal
> human hearing? A counter-move to that could be that services like
> SilverPush could blast audio within human hearing ranges but make it
> information dense (it would sound like the spread-spectrum white noise
> blasts that fire and police use in the US to get the attention of cars that
> aren't getting out of their way).
>

I understand your concern perfectly.

However, I do not think users should have no control over this this (after
all, it's MY browser!). They can, after all, mute their speakers on their
desktop OS. I very regularly do so. In fact, I mostly mute all the
YouTube's or so. Even more so, what if I use several (different) browsers
at the same time - and one window is muted by default. What about this use
case? And what about Private Browsing?

If the current Permission API is not granular enough, we should consider
changing it. I am actually already thinking about it while working on some
Device/Sensors API analysis.

But the avenue of limiting the possible sounds to the human range is also a
good way to go.


>
> I don't see an easy answer to this. Would love to hear others' thoughts.
> We might want to devote some time on a future PING call to this and invite
> interested folks from public-audio to join.
>

Just because it's not easy, doesn't mean we should not speak about this.

Best
Lukasz