Skip to main content

Browser Extension Downloads

If a term is unfamiliar, open the Glossary.

Use this guide when installing the Dralvia browser extension from the workspace workspace.

Workspace: #/browser-extension-downloads

What this page gives you​

  • A first-screen rollout summary for release channel, managed policy status, and recommended install path.
  • Latest extension bundle version.
  • Zip/checksum download options.
  • Release manifest and optional detached signature download options.
  • Optional Chrome Web Store link (if configured).
  • Quick manual installation steps.
  • Managed Chrome and Edge ExtensionSettings policy bundles derived from your Dralvia extension policy assignments.
  • Chrome and Edge force-install list payloads for the Dralvia extension itself when a stable extension ID and update URL are configured.

First-screen route behavior​

The workspace now separates three kinds of state so operators can tell what failed immediately:

  • release metadata state
  • managed browser policy bundle state
  • copy/download action failures

This matters because a missing release does not necessarily mean the managed policy export path is broken, and a failed copy action does not mean the route data itself is stale.

Step-by-step installation​

Before you start, generate or copy your workspace token. This is your workspace API key:

  • In Dralvia Admin, open #/api-keys (the API Keys route).
  • First time in this workspace: click Generate API Key. The key is valid for 12 months with automatic renewal.
  • Already have a key: copy the existing value, or click Rotate if you need to replace it.

The value you copy from #/api-keys is the same string you paste into the extension below.

  1. Open #/browser-extension-downloads.
  2. Click Refresh release.
  3. Download the zip, manifest, and checksum (and detached signature if your release publishes one).
  4. Unzip locally.
  5. In Chrome, open chrome://extensions.
  6. Enable Developer mode.
  7. Click Load unpacked and select the unzipped folder.
  8. Right-click the Dralvia extension icon and choose Options.
  9. Paste the API key you copied from #/api-keys into the Workspace token field and click Save.
  10. Open the extension popup on any page and confirm it shows Connected instead of Guest mode.

Important:

  • For manual ZIP install, the workspace token is pasted into the extension Options page. It is stored locally in the browser and is never embedded in the ZIP or in any extension source file.
  • Managed browser policy always overrides any local Options value, so enterprise rollouts stay centralized.
  • The manifest captures the release hash and download endpoints for audit or MDM handoff.
  • If a signature is present, verify it with your browser-extension public key before broad rollout.
  • Manual install is intended for evaluation and small workspaces. Enterprise deployment should use managed policy (see below).

Integrity verification​

The downloads page can expose four browser-extension artifacts:

  • ZIP bundle
  • SHA-256 checksum
  • Release manifest JSON
  • Detached signature (.sig) when the release was signed

Example verification command:

openssl dgst -sha256 -verify dralvia-browser-extension-public.pem \
  -signature dralvia_extension_v1.0.7.zip.sig \
  dralvia_extension_v1.0.7.zip

For large deployments, do not install per PC manually.

  1. Force-install via Intune, Jamf, GPO, or Chrome enterprise policy.
  2. Set managed policy dralviaExtensionConfig with:
    • apiBase: https://dralvia.tech/api
    • tenantApiKey: CHANGE_THIS_TO_YOUR_TENANT_API_KEY
    • optional deviceLabel and deviceId
    • optional deviceTrust (managed or unmanaged)
    • optional deviceOwnership (corporate or byod)
    • optional workforceType (employee or contractor)
  3. Extension auto-enrolls and auto-renews the workspace-scoped extensionToken without user intervention.

Use this path when you want no user sign-in dependency and centralized fleet rollout. Enterprise teams should pull the exact managed-policy payload from this page instead of copying setup details from Browser Protection inventory screens.

Managed browser governance bundle​

The downloads workspace now also exposes a managed-browser policy bundle for Chrome and Edge.

Use it when you want the browser itself to enforce extension-governance actions:

  • block and prevent_install become installation_mode = blocked
  • remove becomes installation_mode = removed
  • allow, warn, and monitor stay installation_mode = allowed

Operational flow:

  1. Observe extension inventory in #/browser-security.
  2. Set Dralvia policy actions for risky extensions.
  3. Open #/browser-extension-downloads.
  4. Copy or download the Chrome/Edge ExtensionSettings payload.
  5. Paste that payload into your MDM, GPO, Intune, Jamf, or browser-enterprise policy channel.

Important:

  • This bundle governs third-party extensions by extension ID.
  • The downloadable Dralvia ZIP now ships with manifest/checksum and optional detached signature metadata, but it remains a manual/unpacked artifact.
  • Force-installing the Dralvia extension itself still requires a signed CRX or a store-hosted package with a stable extension ID and update URL.

Dralvia force-install readiness​

When the platform knows both of these values:

  • stable extension ID
  • stable update URL

the downloads workspace also exposes Chrome and Edge ExtensionInstallForcelist values for the Dralvia extension itself.

Example value:

[
  "abcdefghijklmnopabcdefghijklmnop;https://clients2.google.com/service/update2/crx"
]

Use this only after your extension package is actually hosted behind that update URL. If those values are missing, the workspace correctly stays in manual ZIP mode.

Example: 1000 endpoints in one workspace​

You can enroll many endpoints with the same workspace API key.

  • Use one shared workspace API key for the managed workspace policy.
  • Ensure each endpoint gets a unique deviceLabel and/or deviceId from your MDM inventory variables.
  • Set deviceTrust, deviceOwnership, and workforceType from MDM inventory variables when you want browser DLP adaptive access controls for unmanaged, BYOD, or contractor contexts.
  • Result: one workspace scope, many uniquely identified devices in telemetry, no per-user manual enrollment tickets.

Example managed policy payload:

{
  "dralviaExtensionConfig": {
    "apiBase": "https://dralvia.tech/api",
    "tenantApiKey": "CHANGE_THIS_TO_YOUR_TENANT_API_KEY",
    "deviceLabel": "${HOSTNAME}",
    "deviceId": "${ASSET_ID}",
    "deviceTrust": "managed",
    "deviceOwnership": "corporate",
    "workforceType": "employee"
  }
}

Verification checklist​

  • Extension icon is visible.
  • Risk overlays appear on supported pages.
  • Browser activity signals appear in #/tenant-browser-beacons (if enabled).

Recent changes​

  • Improved extension packaging and manual enrollment configuration. The customer ZIP now contains only the files Chrome needs at runtime, and a built-in Options page lets small workspaces paste their workspace token directly into the extension without managed browser policy.

SWG navigation rollout validation​

Use this short playbook when validating workspace browser blocking:

  1. Add or confirm a workspace block rule in #/swg-policy.
  2. In Web Access Protection, refresh Compiled browser navigation rules and confirm the blocked host and policy_version.
  3. If you want validation to stay audit-only first, set swg_navigation_enforcement=false for the workspace or managed policy group until that compiled feed looks correct.
  4. Remove that dry-run override only for the validation workspace or managed policy group.
  5. Browse to the test host in a managed browser and confirm the expected interstitial appears:
    • #/blocked for workspace block
    • #/warn for workspace monitor
  6. Open #/browser-security and confirm the SWG navigation enforcement strip reflects the block within one ingest cycle.
  7. For Firefox validation, also set managed config swgNavigationFirefoxFallback=true or swg_navigation_firefox_fallback=true before testing.

Opt-out path:

  • To return the workspace to dry-run, set workspace browser policy swg_navigation_enforcement=false or managed/local extension config swgNavigationEnforcement=false / swg_navigation_enforcement=false.

Self-check playbook​

Use this 5-step isolation flow before escalating:

  1. Configuration: confirm required inputs are present and formatted correctly.
  2. Permission: confirm your role can perform the action (401/403 usually indicates authz/authn mismatch).
  3. License/feature: confirm the feature is enabled for your workspace plan and module toggles.
  4. Quota/rate limit: check for 429 responses and cooldown windows.
  5. Service health: if you see 5xx, retry once after 30-60 seconds and capture exact error text.

If still failing, escalate with workspace ID, UTC timestamp, route, action, payload shape (no secrets), and screenshot/error response.

Troubleshooting​

"No browser extension bundle available yet"​

  • Workspace release is not published.
  • Contact support for release enablement.

Extension loads but no telemetry​

  1. Confirm extension permissions are granted.
  2. Confirm network access to Dralvia endpoints.
  3. Re-check workspace settings for beacon collection.

Managed policy bundle looks empty​

  • No extension release is published yet.
  • No observed extensions currently have a Dralvia policy action set.
  • Refresh #/browser-security, assign policy state, then refresh the downloads page again.

Who this is for​

This guide is for workspace owners, workspace admins, and security operators who need clear, repeatable steps without support intervention for day-to-day execution.

Role-based start here​

  • Workspace Owner: Start with Before you start, then complete Step-by-step and Known limits and rate limits.
  • Workspace Admin: Focus on Step-by-step, What each button does, and API and automation.
  • Security Analyst: Start at Day-2 operations and Troubleshooting, then use API error quick reference.
  • Integrator/Engineer: Start at API and automation, then validate with Step-by-step and FAQ.

Before you start​

Use this short checklist before making changes:

  1. Confirm you are signed into the correct workspace account.
  2. Confirm your role includes the permissions needed for this page.
  3. Confirm your browser session is fresh (if pages behave unexpectedly, sign out/in once).
  4. Confirm required prerequisites (API keys, agent enrollment, license, upstream integrations) are already in place.

Step-by-step​

Follow this sequence for predictable results:

  1. Open the workspace from the workspace menu.
  2. Review current status/health/last update indicators before making changes.
  3. Apply one change at a time and save.
  4. Run the available validate/probe/refresh action.
  5. Confirm the expected output appears (status change, new event, successful result).
  6. If behavior is not as expected, use Troubleshooting below before repeating actions.

Day-2 operations​

After initial setup, keep this surface healthy with a simple routine:

  1. Daily: verify data freshness and error banners.
  2. Weekly: review trends, limits, and failed actions.
  3. Monthly: review permissions, keys/tokens, and stale entities.
  4. After any incident: capture evidence and update your internal operating notes.

What each button does​

Button labels can vary by module, but behavior is consistent:

  • Refresh: reloads the latest data from backend APIs without changing configuration.
  • Save: persists workspace-scoped configuration changes.
  • Run/Probe/Validate: executes a non-destructive health or verification action.
  • Download: fetches workspace-scoped artifact(s) (for example bundle, checksum, signature, or report).
  • Verify: checks integrity/consistency and returns pass/fail details.
  • Enable/Disable: toggles module behavior for your workspace; audit evidence should be recorded.

If a button appears disabled, check role permissions, required fields, and workspace license/feature entitlement first.

API and automation​

Everything in this page should remain workspace-scoped. If your team prefers automation, use the corresponding API endpoints with the same guardrails as the UI:

  • Use authenticated requests bound to your workspace context.
  • Use idempotency/retry controls where available.
  • Validate outcomes in the UI after automated runs.

If your endpoint mapping is not obvious, start from Help Center and follow the linked API docs.

Next best actions​

After finishing this page, continue with related workflows so your workspace setup stays end-to-end complete:

FAQ​

Q: I clicked save but nothing changed. A: Refresh once, confirm permissions, and verify required fields.

Q: Why do I see missing API key/unauthorized errors? A: Confirm your workspace API key or session is valid and mapped to the correct workspace scope.

Q: Can non-admin users use this page? A: Usually read-only access is possible; write actions require workspace-admin or equivalent roles.

Next steps​

After finishing this guide:

  1. Validate the result in the related dashboard/workspace.
  2. Export or capture evidence if this affects compliance/incident operations.
  3. Share the same runbook internally so other operators follow identical steps.
  4. Return to Help Center for adjacent workflows.

API error quick reference​

Use this matrix when a UI action fails with an HTTP/API error.

ErrorMeaningWhat to do now
401 UnauthorizedSession token is missing/expired or request is not authenticated.Sign out/in, refresh once, then retry. Confirm your session is active in the correct workspace.
403 ForbiddenYou are authenticated but your role is not allowed to perform this action.Confirm your role includes the required permission for this button/action. Ask workspace admin to grant access.
404 Not FoundThe route/resource does not exist in current workspace context (or feature not enabled).Confirm URL/route, workspace context, and feature availability. Refresh and retry; if persistent, capture timestamp and route and contact support.
429 Too Many RequestsRate limit/quota window was exceeded.Wait for cooldown/reset window, retry once, then reduce burst traffic/backoff if automated.
500 Internal Server ErrorBackend failed unexpectedly while processing the request.Retry after 30-60 seconds. If still failing, escalate with workspace ID, UTC time, route, action, and full error text.

Known limits and rate limits​

These limits can vary by plan and feature, but behavior is consistent:

  • Burst traffic can trigger 429 Too Many Requests.
  • Workspace quotas apply per feature/module and reset on configured windows.
  • Repeated retries without backoff can extend recovery time during saturation.

Recommended operator behavior:

  1. Retry once after cooldown for 429 responses.
  2. Use exponential backoff in automation.
  3. Monitor usage/quota dashboards for sustained high utilization.
  4. Request quota review when normal workload regularly approaches limits.