MediaDevices Identity and Virtual Camera Privacy in Browser Workflows

Media device enumeration is useful for choosing a camera or microphone, but it is not evidence that a page can capture from that device. enumerateDevices() reports a permission- and policy-filtered view of input and output devices; getUserMedia() separately requests access and attempts to open a real source. A virtual camera must be supplied by software outside that enumeration step. Treat the list as both a privacy-sensitive browser surface and a limited selection aid: explain why media is needed, request only the needed stream, and keep the active source visible. BotBrowser can control how this enumeration is reported, but it does not create the source, grant permission, or guarantee a usable stream.

This distinction matters when reviewing browser identity. A page may learn that a camera or microphone category exists before it can read a useful label, yet that result says nothing by itself about consent, hardware health, or stream availability. For adjacent topics, see browser permission fingerprinting and WebRTC network identity and privacy.

TL;DR

Enumeration is a permission-filtered discovery view, not proof of capture. BotBrowser can control the profile-backed device list reported to a page, but permission, source availability, and stream capture remain separate browser and operating-system conditions.

Contents

• What device enumeration tells a page
• Why the list is privacy-sensitive and permission-limited
• Enumeration is not a usable media stream
• What a virtual camera adds to the workflow
• A decision path for setup and troubleshooting
• BotBrowser's enumeration control and its limits
• Practical conclusion

What device enumeration tells a page

navigator.mediaDevices.enumerateDevices() returns MediaDeviceInfo records for media inputs and outputs that the browser makes visible in the current context. The record's kind distinguishes audio input, video input, and audio output; label is the user-facing name when disclosure is permitted. The browser can put default capture devices first. The result is therefore an ordered, contextual view, not a complete inventory of everything attached to the computer. The first record is not automatically “the camera”: the list can contain different kinds, including outputs, and default-device ordering is not a user preference. A picker should group or label choices by their reported kind and let the person select the intended input rather than silently choosing index zero.

The limits are important. A page in an insecure context cannot rely on the media-capture APIs being available. Permissions Policy can exclude kinds of devices, and permission state affects which devices and labels are exposed. Before access, a list may omit devices or contain blank labels. After a grant, the visible set or labels can become more informative. A plug-in headset, switched camera, changed browser permission, or different operating-system privacy setting can alter the result. A list captured at one moment should not be treated as a permanent account attribute.

Enumeration can still reveal something even when labels are blank. The presence and kinds of entries can disclose whether a context appears to have camera or microphone choices. Counts, ordering, and label changes may add detail about a device setup. That makes repeated collection a privacy decision, not harmless diagnostics. If the application needs only one selection for a call, keep the list in the interface and avoid sending the full array to analytics. If support needs an error record, retain the narrow result that answers the support question rather than a raw device inventory.

Treat the result as a snapshot. Connecting a headset, enabling a virtual-camera application, changing a permission, or switching to a different computer can change what the browser reports. The Media Capture specification defines a device-change notification for changes visible to a document where a browser supports it, but an application should still refresh its choices at sensible interaction points and handle a selected device disappearing between selection and capture. Support and timing can vary; a notification is not a guarantee that every hardware or operating-system change will be reported immediately in every browser.

This snapshot model affects both privacy and interface design. Showing a refreshed choice list when a person opens the picker is usually more useful than saving a copy as an account attribute. Persisting a specific preference may be appropriate when the user asks for it, but the application should be ready for the choice to be missing or renamed later. Avoid treating a changed count as suspicious activity: a dock, headset, monitor, privacy setting, or virtual source can change the list for ordinary reasons. Conversely, do not claim that enumeration proves a device is available merely because a row remains visible. Keep support language tied to the observation: “the browser reports a video input” is more accurate than “your camera works.”

The diagnostic choices can be kept readable on a narrow screen by treating each result as a short card:

• A video-input entry appears. It supports: the browser reports a video-input choice in this context. It does not prove: that the camera is powered, permitted, or able to deliver frames. Next: ask for the intended stream and handle its result.
• A label is empty or generic. It supports: the context is not receiving a useful device name. It does not prove: that the device is absent or broken. Next: check secure context, policy, permission, and expected label behavior.
• Several entries or a changed order appear. It supports: more than one choice is reported, or the view changed. It does not prove: that the first entry is preferred or that the list is stable. Next: let the user choose and refresh when devices change.
• No matching entry appears. It supports: no matching choice is exposed in this enumeration result. It does not prove: that no physical or virtual source exists anywhere on the system. Next: check the OS or source application, policy, and supported platform path.

The table is a diagnostic boundary: it prevents the common mistake of turning a browser observation into a stronger claim about the user's hardware or consent. The same caution applies to device names. A MediaDeviceInfo.label is a label for a selection interface, not proof of who owns the device or what content it will show. Do not confuse it with the label of a live MediaStreamTrack, which describes a track after capture has begun.

Why the list is privacy-sensitive and permission-limited

Media access uses layered controls. The page must run in a secure context for the relevant interfaces. The browser applies its permission model, and an embedding page may be limited by Permissions Policy. The user can also deny access, while the operating system can independently block camera or microphone use. These controls are not interchangeable: a browser-level grant does not mean that the operating system can supply frames, and an operating-system setting does not itself grant a web origin permission.

The browser may expose only default devices or withhold labels until the origin has permission to capture. This is a deliberate information boundary. Do not tell users that enumeration always gives a full device list, and do not assume that a blank label is a bug. Instead, explain the next meaningful action: confirm that the page was opened securely, check whether an embedding policy permits the requested kind, use the browser's permission control when appropriate, and then retry the user-initiated workflow. Avoid prompting for a stream solely to reveal labels if the product has no capture purpose.

This boundary is relevant to fingerprinting because a set of reported media choices can vary between environments. A site that collects the values can add them to a broader browser profile. The privacy response is data minimization and a clear reason for access, not a promise that enumeration is secret or identical everywhere. deviceId is unique to the calling origin and may persist across sessions under the browser's privacy model, but clearing storage or using private browsing can rotate it. groupId is generated per document and is not stable across browsing sessions. Neither is a permanent identity. Do not retain device labels, counts, or identifiers longer than the selection or support task needs. Do not use the array as an authentication factor or as a substitute for a user-selected identity.

The user-facing control should match the actual request. Before starting, state whether the session needs audio, video, or both; identify the destination and any recording behavior; and explain what remains available if one permission is refused. A microphone-only support call should not require a camera grant. A settings view that only helps a user choose a source should not quietly start recording. Keep a visible route to change the choice or stop capture, and make those controls accessible without relying on a preview image.

Enumeration is not a usable media stream

enumerateDevices() answers a discovery question: which device records does this page currently receive? getUserMedia() answers a different question: can the browser, after the applicable permission decision, open a requested audio or video source and return a MediaStream? A successful list lookup is not a successful capture. Conversely, a page may request a default source without first building a custom device picker. The two operations belong to different steps and can produce different outcomes.

A getUserMedia() request can be rejected because the user denies it, the browser or operating system blocks the capability, the context is not eligible, or no requested source is available. A request can also remain pending while the user has not answered the prompt. The application should handle each result without describing it as an enumeration failure. Keep a no-camera or no-microphone path where the product supports one; do not repeatedly ask for the same permission after a refusal without a new user action.

When capture succeeds, inspect and display the selected source and the active state. The user needs to know whether the call is using an integrated camera, a headset microphone, or a different input. If a device is disconnected during a session, report that condition and let the user decide whether to select another source. A silent switch can change what is captured and can cross a privacy expectation even if the call stays connected. Stopping the active media track ends that capture; it is not the same operation as revoking the site's permission for a later request. Provide separate, clearly named controls when both actions are available.

Keep the concepts separate in logs and support screens: reported device choices, permission state, capture request result, selected track, and active/ended track state are different facts. A small state record can help support determine whether the page never found a choice, permission was denied, the OS blocked the source, or capture ended after device removal. Avoid storing media content or a full device list just to distinguish those cases.

What a virtual camera adds to the workflow

A virtual camera is a camera source provided by an installed application or operating-system integration. It may combine a scene, presentation, test pattern, or other approved visual input and expose that source to applications that can use it. The browser does not create this source just because a page enumerates devices, and a name in an enumeration result does not establish that the owning application is running or producing frames.

The source has its own lifecycle. Start the approved source application before the browser capture step when that workflow requires it. Then let the user select or request the intended camera through the ordinary browser path. The browser still applies its permission controls, and capture still depends on the source being available. When the work is over, stop the media track and close or disable the virtual source according to the application's normal controls. These are separate actions: ending a browser stream does not necessarily quit the source application, while quitting the source can make an already selected track end or fail.

Use a clear name that describes the purpose, such as “Presentation camera,” and identify whether the feed is a live camera, composed scene, or test image. Preview the actual content before sharing it; a prepared scene can expose account details or internal material just as a physical camera can expose a room. A virtual camera is appropriate for legitimate production, training, accessibility, or testing workflows, but it does not reduce the need for consent or content review. Browser screen sharing is a separate, user-selected capture path; it is not a camera device returned by enumerateDevices() and should not be described as a virtual camera.

When the source is missing, debug the chain in order: confirm that the source application is available and has the intended output, check whether the operating system exposes it to browsers, inspect the browser's current enumeration result, then test a user-initiated capture request. Each step answers a different question. Do not treat a missing browser entry as proof that the API can be bypassed, and do not promise that changing an enumerated list will create a working stream.

A decision path for setup and troubleshooting

Use this compact decision path to choose the next check without conflating discovery, consent, and capture. It is useful in a product settings page, a support runbook, or a release check because each outcome points to a bounded action.

Use the same decision path as short cards when the viewport is narrow:

• The page is not in a secure context or the required API is unavailable. Meaning: the normal browser media workflow cannot complete here. Action: move to the supported secure page or explain the limitation.
• A device is not listed. Meaning: the current policy- and permission-filtered view has no matching choice. Action: check embedding policy and OS/source availability; do not infer physical absence.
• A device is listed, but the label is blank. Meaning: discovery occurred without a disclosed name. Action: continue only if the user can make a safe choice; check permission behavior when a name is necessary.
• The user denies the request. Meaning: capture was not authorized in the browser. Action: keep the documented alternate path and respect the decision.
• Permission is granted but capture fails. Meaning: authorization did not make the source usable. Action: check OS privacy controls, source-app state, device connection, and the exact request failure.
• Capture starts and later ends. Meaning: a live track was opened, then stopped or lost. Action: show that capture ended, release related UI state, and ask before selecting a replacement.

For a new workflow, begin with the least capability that can complete the task. State the purpose, request only the required kind, and test the declined-permission path. Then test a missing or disconnected source, a changed device list, and a successfully stopped stream. On mobile and desktop, preserve the same meaning even if the browser uses different permission UI. Review analytics and logs at the same time: record only facts needed to operate the workflow, not media contents or raw lists by default.

For a virtual-camera workflow, add two checks: the external source application is producing the expected scene, and the browser has a real selected track after consent. The first does not prove the second. Confirm the displayed source with the user before sharing, and make the stop action available throughout the session. A useful release result is an observable user outcome, not merely a non-empty enumeration array.

BotBrowser's enumeration control and its limits

BotBrowser documents --bot-media-devices as a control over how navigator.mediaDevices.enumerateDevices() reports audio and video devices. Its documented default is to return the profile's device list without requiring an extra flag. This can help keep the reported device view aligned with a chosen browser profile when a media workflow depends on that view. BotBrowser controls reported enumeration, but it does not create a virtual camera, grant browser or operating-system permission, or guarantee that the selected source can produce a MediaStream.

That control is about reported enumeration. It does not install or create a virtual camera, start a source application, grant browser or operating-system permission, or guarantee that a selected source can produce a MediaStream. The page and platform still follow the normal permission and capture rules. Validate the reported list separately from permission and stream behavior, and describe only the result that was actually checked.

In practical terms, a profile-level device list can make the discovery surface predictable for an intended setup, while the user-facing workflow remains responsible for consent, source selection, capture failure, and stopping the stream. Keep those boundaries explicit in support instructions and product language.

Practical conclusion

Treat enumeration, permission, and stream availability as separate checks. Use BotBrowser's profile-backed enumeration control only to make the reported discovery view consistent with the intended profile; keep user consent, external virtual-camera software, operating-system access, and stopping the stream visible in the workflow.

Sources

• BotBrowser media devices documentation
• MDN: MediaDevices.enumerateDevices()
• MDN: MediaDevices.getUserMedia()
• W3C: Media Capture and Streams