[privacy] Exposing data to an origin: fingerprinting

Does this specification expose any other data to an origin that it
doesn’t currently have access to?

Yes. When giving various information on available AudioNodes, the Web
Audio API potentially exposes information on characteristic features
of the client (such as audio hardware sample-rate) to any page that
makes use of the AudioNode interface. Additionally, timing information
can be collected through the AnalyserNode or ScriptProcessorNode
interface. The information could subsequently be used to create a
fingerprint of the client.

from Tom Ritter:
https://lists.w3.org/Archives/Public/public-privacy/2017OctDec/0017.html

If a UA wanted to report generic information for a user, effectively
lying about audio hardware sample-rate and the rest) so that every
user presented the same data to prevent fingerprinting - are you able
to recommend sensible defaults in the draft? Or what a UA should
consider when choosing sensible defaults?

For the sample rate, typical values would be 44100 or 48000. These are all common values in use.

@rtoy

Apart from some high-end outliers (192k/24bit for example) the majority of uses are as @rtoy says going to be the CD rate of 44100 or the DAT rate of 48000, even if the actual hardware can go higher (96000 commonly) it is typically set to one of those two in practice.

The additional fingerprinting surface area is thus non-zero, but small.

Speaking not as chair, there are so few sample rates in use out there that it is hard to see how sampleRate can be useful.

As far as timing information goes, isn't it the case that any CPU intensive task in JS yields fingerprintable results? To what extent do these add fingerprinting exposure to what exists already?

Waiting for response from security and privacy review.

As far as timing information goes, isn't it the case that any CPU intensive task in JS yields fingerprintable results? To what extent do these add fingerprinting exposure to what exists already?

They can, certainly, but efforts in reducing the resolution of timers and jittering them have made those efforts less effective.

UAs could certainly have a mode where the sample-rate is forced to either 44.1kHz or 48kHz. Additionally, AudioDestinationNode.maxChannelCount could be also constrained to always return 2 (stereo, which is certainly the immense majority of setups).

This would not really reduce the usefulness of the API by much and reduce the exposed entropy by a bit. Additionally, it is trivial to implement.

Does any implementer has statistics on which sample-rate is the more common? It probably does not matter in practice as long as it's one of those two.

Chrome has statistics on the sample rates. I'm not sure I can share exact numbers, but suffice to say that over 95% of all systems use either 44.1 kHz or 48 kHz. However, there is a huge variety of rates. And we know some people use 192 kHz because people filed issues about Chrome not working at that rate.

I agree that stereo is by far the most common (sadly, looks like we have no statistics on that), I think there are people who do want to support 5.1 audio systems. I'm reluctant to set maxChannelCount to 2; we should allow at least up to 6.

Just a clarification, this is not intended to be the normal settings for a normal UA.

A specific UA, or a setting in an existing UA would result in having, say, always stereo output and 44.1kHz sample-rate, allowing users willing to sacrifice some feature for some increased privacy to do so.

For example, going to about:config in Firefox and toggling privacy.resistFingerprinting will change a bunch of APIs, but it's not the default configuration.

The spec now says:

Does this specification allow an origin access to aspects of a user’s local computing environment?

Not directly; all requested sample rates are supported, with upsampling if needed. It is possible to use Media Capture and Streams to probe for supported audio sample rates with MediaTrackSupportedConstraints. This requires explicit user consent. This does provide a small measure of fingerprinting. However, in practice most consumer and prosumer devices use one of two standardized sample rates: 44.1kHz (originally used by CD) and 48kHz (originally used by DAT). Highly resource constrained devices may support the speech-quality 11kHz sample rate, and higher-end devices often support 88.2, 96, or even the audiophile 192kHz rate.

Requiring all implementations to upsample to a single, commonly-supported rate such as 48kHz would increase CPU cost for no particular benefit, and requiring higher-end devices to use a lower rate would merely result in Web Audio being labelled as unsuitable for professional use.
https://webaudio.github.io/web-audio-api/#priv-sec

Pinged commentor here
https://lists.w3.org/Archives/Public/public-privacy/2018JanMar/0027.html

Response at
https://lists.w3.org/Archives/Public/public-privacy/2018JanMar/0028.html

On 4: it would force resampling if an unsupported rate was requested (it does this today). Otherwise it would be clearly observable.

Explain more? What, precisely, happens?

Generating an error for unsupported rates enables further fingerprinting. You'd know the user doesn't have this sample rate. By silently resampling, you can't tell if the user has that rate or not. It just works.

"what precisely happens" - see previous post: any time a sample rate that is not natively supported is selected, the AudioContext is still created at the requested rate, and resampling will occur between that AudioContext and the actual audio device. This isn't observable from the API.

The stipulation I was making is that if a sample rate that is not 44.1k or 48k is requested (e.g. 96kHz), and that rate IS natively supported by the hardware, the system will send the AudioContext output to the output (rather than creating it at 96kHz, downsampling to 48kHz and then upsampling back to 96kHz). This will enable higher bit rates without quality or performance loss, while not leaking fingerprintable bits (this isn't observable since you can't get access to those bits (the actual bits sent out from the device), and you'd have to use user-prompt-protected browsing of the media devices to know that it's available).

Sounds good to me.

So, the conclusion is that the comments in #1457 (comment) are what we want to say and do in the spec. More or less.

Sounds like a plan.

Fix WebAudio#1457: Privacy for sample rates

@svgeesus

@svgeesus Manipulating the flags on this issue won't work. I'll close the tracking issue.

@tjwhalen

@tjwhalen Sam said he would close the tracking issue but did not. To tidy up, would you mind doing so?

Fix WebAudio#1457: Privacy for sample rates (WebAudio#2223)

Navigation Menu

Repository navigation

[privacy] Exposing data to an origin: fingerprinting #1457

36 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[privacy] Exposing data to an origin: fingerprinting #1457

Description

Activity

rtoy commented on Nov 30, 2017

svgeesus commented on Dec 14, 2017

joeberkovitz commented on Dec 14, 2017

mdjp commented on Jan 11, 2018

tomrittervg commented on Feb 6, 2018

padenot commented on Feb 6, 2018

rtoy commented on Feb 6, 2018

padenot commented on Feb 6, 2018

svgeesus commented on Mar 26, 2018

svgeesus commented on Mar 27, 2018

svgeesus commented on Apr 26, 2018

36 remaining items

samuelweiler commented on Jun 26, 2020

rtoy commented on Jun 26, 2020

cwilso commented on Jun 26, 2020

samuelweiler commented on Jul 2, 2020

rtoy commented on Jul 14, 2020

rtoy commented on Jul 16, 2020

samuelweiler commented on Mar 18, 2021

svgeesus commented on Sep 16, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions