Pref to disable Web Audio API

RESOLVED FIXED in Firefox 51

Status

()

Core
Web Audio
P2
normal
Rank:
25
RESOLVED FIXED
2 years ago
a year ago

People

(Reporter: eriador, Assigned: padenot)

Tracking

47 Branch
mozilla51
Points:
---

Firefox Tracking Flags

(firefox51 fixed)

Details

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160630070928

Steps to reproduce:

-


Actual results:

AudioContext, DynamicsCompressor and OscillatorNode are being used in the wild to "fingerprint" web users, as reported by researchers: https://techcrunch.com/2016/05/19/audio-fingerprinting-being-used-to-track-web-users-study-finds/

(online tests here: https://browserprint.info)


Expected results:

An option to disable Web Audio is needed to protect users privacy. It appears this preference was introduced as "media.audio_data.enabled" per this request https://bugzilla.mozilla.org/show_bug.cgi?id=665598 but it's not available anymore in the latest versions of Firefox.

Comment 1

2 years ago
Chris, any idea?
Component: Untriaged → Web Audio
Flags: needinfo?(cpearce)
Product: Firefox → Core
revectoring to Padenot

Request is for a pref to disable WebAudio to block fingerprinting
Flags: needinfo?(cpearce) → needinfo?(padenot)
Whiteboard: [needinfo 2016/07/21 to reporter]
I am not a WebAudio module peer. Paul or Karl can make this call.
Flags: needinfo?(karlt)
(Assignee)

Comment 4

2 years ago
It's unclear to me just yet _why_ this works (and I clearly see some methods are better than others), but it's easy to do in any case.
Flags: needinfo?(padenot)
(Assignee)

Comment 5

2 years ago
Created attachment 8773721 [details]
Bug 1288359 - Add a pref to disable the Web Audio API.

Review commit: https://reviewboard.mozilla.org/r/66456/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/66456/
(Reporter)

Comment 6

2 years ago
I see status is still "unconfirmed". Please let me know if there is anything else required from my side.
Assignee: nobody → padenot
Status: UNCONFIRMED → NEW
Rank: 25
Ever confirmed: true
Priority: -- → P2
Whiteboard: [needinfo 2016/07/21 to reporter]

Comment 7

2 years ago
Dear devs, is there any hope to see this simple patch land in a future version of Firefox? thx.
(In reply to pollo from comment #7)
> Dear devs, is there any hope to see this simple patch land in a future
> version of Firefox? thx.

Need a try run probably, and the code to be reviewed. padenot was on PTO since he wrote the patch; just got back.
Flags: needinfo?(padenot)
(Assignee)

Comment 9

2 years ago
Green try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=030b5fd3c6a9d88268e775b73332b6f8eb60c0f2 (this patch is at the bottom of the queue)
Flags: needinfo?(padenot)
(Assignee)

Updated

2 years ago
Summary: Pref to disable Web Audio API extension → Pref to disable Web Audio API
Comment hidden (mozreview-request)
(Assignee)

Comment 11

2 years ago
Karl, do you agree we should offer this option? It's a bit unclear to me why this works, but it's been successful in identifying a couple different computers I have.

I think this can break the web audio devtools, I'll ping Jordan.

Comment 12

2 years ago
mozreview-review
Comment on attachment 8773721 [details]
Bug 1288359 - Add a pref to disable the Web Audio API.

https://reviewboard.mozilla.org/r/66456/#review75356

Guessing you meant to flag me for review here, but bugzilla didn't notice, so I'm not sure.

Looks good to me thanks.  The previous version of this was called media.webaudio.enabled but I don't mind which you choose.

I'm skeptical re the usefulness of the fingerprinting here.  Having a toggle on the availability of these objects may provide almost as much information (1 bit) as the fingerprinting tests.

Might need a dom peer to look over this.  I don't know the rules, but I know there are things that dom peers want to see.
Attachment #8773721 - Flags: review?(karlt) → review+
Flags: needinfo?(karlt)
I was looking at an older version of the bugzilla page when I wrote the previous comment, but I don't see any harm in adding this option.

The fft test might be just based on the speed of being able to run successive ffts compared against the clock of the audio graph.  It was described as somewhat unreliable.  I don't know what is happening with DynamicsCompressor.  Maybe the non-sse parts are not IEEE math on x86.
(Assignee)

Comment 14

2 years ago
Comment on attachment 8773721 [details]
Bug 1288359 - Add a pref to disable the Web Audio API.

Smaug, does that sound like an addition we should make? Web Audio will still be enabled by default, but that allows reducing the entropy for people who need it.
Attachment #8773721 - Flags: review?(bugs)

Comment 15

2 years ago
mozreview-review
Comment on attachment 8773721 [details]
Bug 1288359 - Add a pref to disable the Web Audio API.

https://reviewboard.mozilla.org/r/66456/#review75402

This pref should be added to all the WebAudio interface.
Otherwise a page doing something like
if ("AudioNode" in window) {
  // try to use web audio
}
will break.
Attachment #8773721 - Flags: review?(bugs) → review-
Comment hidden (mozreview-request)

Comment 17

2 years ago
mozreview-review
Comment on attachment 8773721 [details]
Bug 1288359 - Add a pref to disable the Web Audio API.

https://reviewboard.mozilla.org/r/66456/#review75458

Hopefully nothing was missed here :)
Attachment #8773721 - Flags: review?(bugs) → review+
(Assignee)

Comment 18

2 years ago
I got all the interface name using running some javascript on the spec document, it should be exhaustive.

Comment 19

2 years ago
Pushed by paul@paul.cx:
https://hg.mozilla.org/integration/mozilla-inbound/rev/2e3e036ccb2a
Add a pref to disable the Web Audio API. r=karlt,smaug
(Assignee)

Comment 20

2 years ago
This will be available in Firefox 51.

Comment 21

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/2e3e036ccb2a
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox51: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla51

Comment 22

2 years ago
Did we look into the fingerprinting vector here and decide that it is useful to protect against?

From what I can tell, the bit exposed here reveals the implementation of the browser engine, including which OS you're on, which is already exposed.  Based on some testing, it seems that different versions of Firefox on the same machine all return the same "fingerprint", and even more interestingly, Chrome and Opera on the same machine also expose the same "fingerprint."

I think the only real bit exposed here is the floating point code shipped which calculates the audio samples.  Wouldn't it have been a better idea to expose a pref which adds some noise into some of our floating point math instead of disabling the whole API on Tor Browser?
Flags: needinfo?(padenot)
Flags: needinfo?(karlt)
(Assignee)

Comment 23

2 years ago
(In reply to :Ehsan Akhgari from comment #22)
> I think the only real bit exposed here is the floating point code shipped
> which calculates the audio samples.  Wouldn't it have been a better idea to
> expose a pref which adds some noise into some of our floating point math
> instead of disabling the whole API on Tor Browser?

That might be it, however we don't have time at the moment to do a more in-depth analysis, and disabling was an easy patch to write. Web Audio API is not a feature that is essential to day-to-day browsing at the moment.

I'm happy to review patches that do something less drastic, though. The API surface and code base is large, so it might be a bit complicated to implement.

Again, this was easy to write and effective. In my testing, I could reliably identify all the machines (including phones) that I own, so I thought it was quite serious and decided to do something.
Flags: needinfo?(padenot)
IMO adding noise would add more cost than this is worth.

If the pref is an unwanted cost, then I'd like to know which test is identifying the machines and further investigate, before resorting to random error.

Using SSE math may help with the DynamicsCompressor, but that is just a guess.

I'm also curious whether merely timing the execution of worker threads is as successful as sampling the audio thread with ffts.
Flags: needinfo?(karlt)
You need to log in before you can comment on or make changes to this bug.