Skip to content
English
Back to IRIS Website
  • There are no suggestions because the search field is empty.

IRIS Clarity Windows Support Extension

How to deploy the IRIS Clarity Windows Support Extension for Chrome and Edge

 Path A — Chrome Web Store

Contact IRIS for the current Chrome Web Store extension ID before proceeding.

Step 1 A — Force-install on Chrome

Add the following registry entry on each managed machine (or push via Intune/GPO):

Key:   HKLM\SOFTWARE\Policies\Google\Chrome\ExtensionInstallForcelist Name:  1  (or any unused integer) Type:  REG_SZ Value: <iris_cws_extension_id>;https://clients2.google.com/service/update2/crx

Replace <iris_cws_extension_id> with the ID provided by IRIS.

 

Step 1 B — Force-install on Edge

Option 1 — reference the Chrome Web Store directly (try this first):

Key:   HKLM\SOFTWARE\Policies\Microsoft\Edge\ExtensionInstallForcelist Name:  1  (or any unused integer) Type:  REG_SZ Value: <iris_cws_extension_id>;https://clients2.google.com/service/update2/crx

Option 2 — use the Edge Add-ons store (if Option 1 causes issues):

Contact IRIS for the Edge Add-ons store ID, then use:

Key:   HKLM\SOFTWARE\Policies\Microsoft\Edge\ExtensionInstallForcelist Name:  1  (or any unused integer) Type:  REG_SZ Value: <iris_edge_extension_id>;https://edge.microsoft.com/extensionwebstorebase/v1/crx
 
Step 2 — Apply and verify

Push the policy via Intune or Group Policy:

  • Intune: Edge is supported natively in the settings catalog. Chrome requires the Google Chrome ADMX template (available from Google). Set each browser as a separate configuration profile.
  • Group Policy: Import the ADMX templates for Chrome and/or Edge. Set ExtensionInstallForcelist under Computer Configuration → Administrative Templates → [Browser] → Extensions.

On a test machine, open chrome://policy or edge://policy and confirm the extension ID appears in the forcelist. Then open the browser — the extension should install within a few minutes.

Updates: handled automatically by Google. No action required from your IT team.

 

Path B — Self-hosted

This path is available immediately and requires no Chrome Web Store approval. You host two files on any HTTPS server you control (examples: Azure Blob Storage, S3, SharePoint, an internal IIS or nginx server).

What you need before starting

  • The .crx file and update_manifest.xml — provided by IRIS
  • An HTTPS file host reachable from your managed machines
  • The extension ID: hoafahidigcfefnficbbajmnijpdedao
Step 1 — Host the extension files
  1. Edit update_manifest.xml (provided by IRIS). Replace the placeholder URL with the full HTTPS path where you will upload the .crx: 
    codebase="https://your-host.example.com/iris/iris-clarity-device-override-x.x.x.crx" version="x.x.x"
  2. Upload both files to your HTTPS host:
    • iris-clarity-device-override-x.x.x.crx
    • update_manifest.xml
  3. Confirm both URLs are reachable from a browser on a managed machine before continuing.
 
Step 2 — Force-install on Chrome
Key:   HKLM\SOFTWARE\Policies\Google\Chrome\ExtensionInstallForcelist Name:  1  (or any unused integer) Type:  REG_SZ Value: hoafahidigcfefnficbbajmnijpdedao;https://your-host.example.com/iris/update_manifest.xml
 
Step 3 — Force-install on Edge
Key:   HKLM\SOFTWARE\Policies\Microsoft\Edge\ExtensionInstallForcelist Name:  1  (or any unused integer) Type:  REG_SZ Value: hoafahidigcfefnficbbajmnijpdedao;https://your-host.example.com/iris/update_manifest.xml
 
Step 4 — Apply and verify

Push via Intune or Group Policy using the same steps as Path A. Verify at chrome://policy / edge://policy on a test machine.

 

Applying updates

When IRIS releases a new version, they will provide a new .crx file and the new version number. Your IT team needs to:

  1. Upload the new .crx to your HTTPS host.
  2. Edit update_manifest.xml — update version and codebase to match the new file.
  3. Re-upload update_manifest.xml.

Managed machines will pick up the update automatically within a few hours. No policy change is needed — the extension ID never changes.

 

Verifying the extension is working

On any managed machine after the policy has been applied:

  1. Open Chrome or Edge and go to chrome://policy / edge://policy. The extension ID should appear in the ExtensionInstallForcelist row.
  2. Go to chrome://extensions / edge://extensions. The IRIS Clarity Device Override extension should be listed as installed and enabled, with a "Installed by your administrator" label.
  3. Join or start any HTTPS-based VoIP call and confirm audio is routing through the IRIS device.

 

Excluding specific sites

If there is a site where users need to select their own microphone (e.g. a recording or broadcast tool), you can exclude it from the extension's rewrite via policy — no change to the extension itself is needed.

Add an ExtensionSettings policy entry for the extension ID with a runtime_blocked_hosts list:

  • Chrome: HKLM\SOFTWARE\Policies\Google\Chrome\ExtensionSettings
  • Edge: HKLM\SOFTWARE\Policies\Microsoft\Edge\ExtensionSettings

Contact IRIS with the list of domains to exclude and they can provide the exact policy value to set.

 

Getting help

For the extension files, extension IDs, or policy value assistance, contact the IRIS team. For policy deployment questions specific to your Intune or Active Directory environment, refer to your MDM documentation or internal IT resources.

 

FAQs

Answers to common technical, security, and deployment questions about the extension.

1. Technical Documentation & Architecture

The extension is a Manifest V3 Chrome/Edge extension with a single component: a content script (inject.js) that patches MediaDevices.prototype.getUserMedia at page load time. There is no background service worker, no popup UI, no options page, and no network communication.

On the first getUserMedia call with an audio constraint, the extension:

  1. Calls the original unpatched getUserMedia({ audio: true }) to unlock device label enumeration
  2. Calls enumerateDevices() and finds the IRIS device by its exact driver label
  3. Caches the resolved device ID for all subsequent calls on that page load
  4. Rewrites constraints to deviceId: { exact: <iris-id> }, which beats Chrome's saved per-site preference

2. Security Documentation

  • No data movement. The extension injects one inert prototype patch. It reads nothing from the page, writes nothing to external services, and makes no network requests beyond the browser's own media device API.
  • No privileged permissions. The manifest declares zero host_permissions, tabs, storage, or webRequest. The only declared surface is a content_scripts entry.
  • Broad surface, narrow behavior. The content script pattern matches https://*/* (required since getUserMedia only works in secure contexts), but the code does exactly one thing: overwrite the audio deviceId before passing the call through to the real browser API.
  • MAIN world scope. Because it runs in the page's MAIN JavaScript world (not an isolated content script context), it can patch the prototype before any page script captures a reference — this is necessary for the override to work, and does not grant any additional browser privileges.
  • No DOM mutation. The extension touches no page elements.

There are no known CVEs or security issues with this extension.

3. Permissions & What It Modifies

Declared manifest permissions: none.

Declared host access: content script matches https://*/* (all HTTPS pages). This is required because getUserMedia only operates in secure contexts — plain HTTP pages cannot request microphone access regardless.

What it modifies at runtime:

  • Patches MediaDevices.prototype.getUserMedia in the JavaScript environment of each HTTPS page.
  • When a page calls getUserMedia with an audio constraint, the extension substitutes the IRIS device ID for whatever deviceId the page requested, using { exact: <iris-id> }.
  • Strips any groupId from the audio constraints (groupId is tied to device ID and would conflict).
  • Preserves all other audio constraints (echoCancellation, noiseSuppression, channelCount, sampleRate, etc.).
  • Does not modify browser microphone permission settings, OS audio settings, or any browser UI.

What it does not modify: video constraints, audio: false requests, non-audio getUserMedia calls, browser permission grants/denials, OS-level audio routing.

4. Configuration Changes & Persistence

There is no persistent configuration. The device ID is resolved fresh on each page load via enumerateDevices() — it is never stored to localStorage, chrome.storage, cookies, or any other persistent store.

This is intentional: Chromium salts device IDs per origin, and IDs change whenever the IRIS application is reinstalled. Persisting an ID would produce stale routing after reinstallation.

Behavior across browser updates: the extension persists across browser updates normally (force-installed extensions are re-applied from the update URL after browser updates). The patch logic requires no reconfiguration after browser or IRIS updates — it re-resolves the device ID by stable driver label on every page load.

The one persistent configuration is the force-install policy entry (ExtensionInstallForcelist), which is managed by IT via Intune/GPO and is not touched by the extension itself.

5. Supported Browser Versions & Known Limitations

Supported browsers: Managed Chrome and Edge on Windows.

Minimum version: Chrome/Edge 111.

Current version: 1.0.2

Known limitations:

Limitation Detail
IRIS loads after Chrome If IRIS isn't running when the first getUserMedia call fires, the extension falls back to "default" for that call and retries on the next. A stream already open on the wrong device will not be rerouted — the page must call getUserMedia again (e.g. reload).
First-call latency The warm-up + enumerateDevices() round-trip adds ~50–100ms to the first getUserMedia call per page. Subsequent calls on the same page are instant (cached ID).
Injection race document_start + MAIN world reliably lands before page scripts in practice, but is not a hard guarantee against a page's very first inline script. Should be verified per platform.
Universal rewrite All HTTPS sites get the rewrite. Web apps that legitimately need device selection (browser DAWs, recording tools) must be explicitly excluded via policy.
Managed browsers only Requires enterprise policy to force-install. Cannot be deployed to unmanaged personal browsers.
Non-Chromium browsers Does not cover Firefox or Safari.

6. Logging, Telemetry & Data Collection

None. The extension collects no data, sends no telemetry, and has no logging output beyond what the browser's own DevTools console shows during normal operation.

There is no analytics, no crash reporting, no remote configuration fetch, and no identifier collection. The extension makes no outbound network requests of any kind.

7. Release Notes, Version History & Update Mechanism

Version history:

Version Notes
1.0.2 Current release — published to Chrome Web Store (unlisted)
Earlier Prior development builds

Release notes are not formally published at this time. The Chrome Web Store listing reflects the current version.

Update mechanism:

  • Chrome Web Store distribution: Google's standard CWS update infrastructure. The browser polls for updates automatically.
  • Policy-managed installs: The ExtensionInstallForcelist policy entry includes the update URL. The browser fetches updates on its normal extension update cycle (roughly every few hours).

No action is required from end users to receive updates — force-installed extensions update silently.

8. Enterprise Deployment

Recommended deployment method: ExtensionInstallForcelist policy, pushed via Intune or Group Policy.

Chrome:

  • Policy name: ExtensionInstallForcelist
  • Registry root: HKLM\SOFTWARE\Policies\Google\Chrome
  • ADMX: Google Chrome ADMX template (must be ingested into Intune or GPO)
  • Entry format: <extension_id>;<update_url>
  • Update URL (CWS): https://clients2.google.com/service/update2/crx

Edge:

  • Policy name: ExtensionInstallForcelist
  • Registry root: HKLM\SOFTWARE\Policies\Microsoft\Edge
  • ADMX: Microsoft Edge administrative templates (built into Intune settings catalog — no import needed)
  • Entry format: <extension_id>;<update_url>
  • Update URL (CWS via Edge): https://clients2.google.com/service/update2/crx (Edge can reference CWS)

Intune note: Configure Chrome and Edge as two separate Intune configuration profiles. Edge is natively supported in Intune's settings catalog. Chrome requires importing the Google Chrome ADMX, or using Chrome's cloud management Intune connector.

Site exceptions: If any sites must be excluded from the rewrite (e.g. a web-based DAW where users need device choice), configure runtime_blocked_hosts under the ExtensionSettings policy for those origins. No code change is needed.

Rollout recommendation: Pilot group → department → full rollout.

9. Impact Assessment, Rollback & Known Risks

Impact:

  • All getUserMedia audio calls across all HTTPS sites on managed browsers will be routed to the IRIS Microphone device.
  • Users' browser-saved microphone preferences and any in-app device selectors are effectively overridden (silently, from the app's perspective).
  • Non-audio requests and sites excluded via policy are unaffected.

Rollout risk: The extension runs on every site. A bug would break microphone capture across the fleet simultaneously. The mitigation is phased rollout with validation before expanding each ring.

Rollback procedure:

  1. Remove or update the ExtensionInstallForcelist policy entry via Intune/GPO.
  2. The browser uninstalls the extension on its next policy refresh cycle (typically within minutes to a few hours).
  3. getUserMedia immediately reverts to unpatched behavior — no residual state.

Rollback is clean because the extension stores no persistent state anywhere.

Key risks:

Risk Likelihood Impact Detection
Silent label-match failure (browser tightens label permissions) Low–moderate High — falls back to "default" silently Validation on browser updates
Injection timing shift (app caches getUserMedia before patch lands) Low–moderate High — patch is a no-op on that platform Validation per platform
Chrome or Edge update breaks world: "MAIN" behavior Low High Pilot ring regression test
Edge diverges from Chrome behavior Moderate Varies Validate both browsers independently

10. Interaction with Twilio, Chromium Browsers & Microphone Selection

Twilio and similar VoIP platforms: These platforms call getUserMedia with an explicit, often stale deviceId (e.g. a previously-selected device saved to their own application state). This is the core problem the extension solves. The patch intercepts the call before Twilio's SDK receives any response, rewrites the deviceId to { exact: <iris-id> }, and forwards the call to the real browser API. From Twilio's perspective, its call succeeded — it just got the IRIS device instead of whatever it asked for. All other constraints Twilio passes (echo cancellation, noise suppression, etc.) are preserved.

Chromium browser interaction: Chrome (and Edge, which shares the same media stack) applies a saved per-site microphone preference at the browser level before getUserMedia reaches page scripts. This means a page-script rewrite to deviceId: "default" can still lose to Chrome's saved preference for that site. Using deviceId: { exact: <iris-id> } with the exact constraint beats the saved preference — this is the central design decision and why the extension works where simpler approaches do not.

Microphone device selection:

  • The IRIS device is resolved by its driver label ("IRIS Microphone (IRIS Clarity)") on each page load.
  • Device IDs are not hardcoded — they change per origin and after reinstallation.
  • The extension uses { exact: <iris-id> } which the Chromium media stack treats as the highest-priority constraint, overriding both the calling page's deviceId and Chrome's saved site preference.
  • If IRIS is not yet loaded when the first call arrives, the extension falls back to "default" for that call and retries on the next one.