1288359 - Pref to disable Web Audio API

Status: RESOLVED FIXED

(Core :: Web Audio, defect, P2)

Description

[eriador]

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

[Loic]

Chris, any idea?

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

revectoring to Padenot

Request is for a pref to disable WebAudio to block fingerprinting

Comment 3

[Chris Pearce [:cpearce (Not reading bugmail)]]

I am not a WebAudio module peer. Paul or Karl can make this call.

Comment 4

[Paul Adenot (:padenot)]

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.

Comment 5

[Paul Adenot (:padenot)]

Attachment: 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/

Comment 6

[eriador]

I see status is still "unconfirmed". Please let me know if there is anything else required from my side.

Comment 7

[pollo]

Dear devs, is there any hope to see this simple patch land in a future version of Firefox? thx.

Comment 8

[Randell Jesup [:jesup] (needinfo me)]

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

Comment 9

[Paul Adenot (:padenot)]

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

Comment 10

[Paul Adenot (:padenot)]

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

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/66456/diff/1-2/

Comment 11

[Paul Adenot (:padenot)]

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

[Karl Tomlinson (:karlt)]

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.

Comment 13

[Karl Tomlinson (: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.

Comment 14

[Paul Adenot (:padenot)]

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.

Comment 15

[Olli Pettay [:smaug][[e-mail]]]

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.

Comment 16

[Paul Adenot (:padenot)]

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

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/66456/diff/2-3/

Comment 17

[Olli Pettay [:smaug][[e-mail]]]

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 :)

Comment 18

[Paul Adenot (:padenot)]

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

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/2e3e036ccb2a
Add a pref to disable the Web Audio API. r=karlt,smaug

Comment 20

[Paul Adenot (:padenot)]

This will be available in Firefox 51.

Comment 21

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/2e3e036ccb2a

Comment 22

[(no longer active)]

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?

Comment 23

[Paul Adenot (:padenot)]

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

Comment 24

[Karl Tomlinson (:karlt)]

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.