Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reminder: 2505 media.navigator.enabled #1099

Closed
Thorin-Oakenpants opened this issue Jan 22, 2021 · 3 comments
Closed

reminder: 2505 media.navigator.enabled #1099

Thorin-Oakenpants opened this issue Jan 22, 2021 · 3 comments

Comments

@Thorin-Oakenpants
Copy link
Contributor

Thorin-Oakenpants commented Jan 22, 2021

overview

media devices

  • is covered by RFP in FF59+: which reports 1 videoinput and 1 audioinput
    • in terms of fingerprinting, we shouldn't alter RFP metrics
  • regardless of RFP, device ids are randomized per domain (or eTLD+1) while it is open: i.e close the domain, reopen it and each device will have new ids
    • the only entropy here is for non-RFP users and concerns the number and type (and maybe order) of inputs and outputs. i.e this belongs in RFP alts
  • enabling media devices does not affect WebRTC being disabled
  • devices require a prompt
    • see about:preferences#privacy Permissions
    • users can set site exceptions (e.g for annoying site prompts)
  • for users who require media devices (e.g. for remote web conferencing or something?), this is just yet another thing they need to troubleshoot

current (webRTC included FYI)

/* 2001: disable WebRTC (Web Real-Time Communication)
 * [SETUP-WEB] WebRTC can leak your IP address from behind your VPN, but if this is not
 * in your threat model, and you want Real-Time Communication, this is the pref for you
 * [1] https://www.privacytools.io/#webrtc ***/
user_pref("media.peerconnection.enabled", false);

/* 2505: disable media device enumeration [FF29+]
 * [NOTE] media.peerconnection.enabled should also be set to false (see 2001)
 * [1] https://wiki.mozilla.org/Media/getUserMedia
 * [2] https://developer.mozilla.org/docs/Web/API/MediaDevices/enumerateDevices ***/
user_pref("media.navigator.enabled", false);

concerns

from earthlng

https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia

If no camera exists with this resolution or higher, then the returned promise will be rejected with OverconstrainedError, and the user will not be prompted.

OverconstrainedError: Because this error can occur even when the user has not yet granted permission to use the underlying device, it can potentially be used as a fingerprinting surface.

Me: if sites were to try to use this for fingerprinting (assuming this FP method still works: I have not tested), I assume they would start with the highest res and work their way down until they got success (i.e it would trigger a prompt), which would give them the metric. This would cause sites prompting for camera when said sites (almost universally) wouldn't have any reason to use the camera = spooky as fuck = drives people away. No site is going to allow that - except maybe sites that require cameras, in which case you probably want to use them (e.g. Zoom etc)

Me also: the entropy, if ever gained, would be small: just think of how many camera resolutions there are: a handful and maybe a long tail

Me again: It is universally easier to get entropy from Media Devices API (is it enabled or not) and a list of devices types, than it is to pull OvercontrainedErrors. Right now, by disabling the API, we stand out (when fingerprinted)

tl;dr: assuming my facts are right: it would be impossible to script this over the majority of sites (scary unexpected prompts), so the metric almost becomes useless. The entropy would be low. Disabling the API is easily detected and would give away far more entropy than a common camera resolution

solution

move 2505 to RFP alts

here's what's in RFP section

 FF59+
   1372073 - spoof/block fingerprinting in MediaDevices API
      Spoof: enumerate devices reports one "Internal Camera" and one "Internal Microphone" if
             media.navigator.enabled is true (see 2505 which we chose to keep disabled)
      Block: suppresses the ondevicechange event (see 4612)

Class, discuss! Change my mind!!

@Thorin-Oakenpants
Copy link
Contributor Author

so this is along the lines of

  • we don't disable geo since the API is easy to FP, and geo is behind a prompt
  • we don't disable appCache since the API is easy to FP, instead we disable the actual storage

@privacyonly
Copy link

It will request for camera access before testing for resolution. Brute forcing resolution is a thing.

So I agree to enable webrtc.

@Thorin-Oakenpants
Copy link
Contributor Author

Not suggesting to enable webrtc. I am suggesting to enable media devices enumeration

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants