You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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);
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!!
The text was updated successfully, but these errors were encountered:
overview
media devices
current (webRTC included FYI)
concerns
from earthlng
https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia
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
Class, discuss! Change my mind!!
The text was updated successfully, but these errors were encountered: