Skip to main content

Browser Extension

Overview​

The Dralvia browser extension provides page‑level scanning and optional prompts for risky destinations. It is designed for workspace users and SOC teams.

What it does​

  • Runs lightweight URL scans against Dralvia when a page loads
  • Can surface warnings and a “Contact Security” action
  • Sends optional browser beacon telemetry (workspace‑scoped)
  • Can report observed third-party extension inventory (plus linked-domain intel from Dralvia scans, trusted-brand-backed publisher verification, and update-channel-aware publisher reputation) when the optional browser management permission is granted in a managed rollout
  • Syncs extension policy assignments and reports enforcement outcomes (observe-first), including disable and removal attempts for managed browsers
  • Can now fetch workspace-scoped browser data-movement policy and trigger browser-time warnings or blocks for high-signal actions such as uploads, explicit file-download clicks, paste events, print, and form submission when the current destination falls inside the workspace DLP scope
  • Can now classify supported browser-time text samples locally for those DLP events and emit only redacted sensitive-data evidence (content_classifier_hits) for clipboard paste plaintext, typed form submission values, and print-page text
  • That same classifier evidence now appears in Browser Protection analyst cards as detected data classes plus redacted hit details, so workspace operators can review what matched without exposing the raw value
  • Can now also consume workspace-defined custom regex classifier patterns from browser DLP policy, so teams can add their own redacted browser-time detectors without rebuilding the extension
  • Can now also extract bounded plaintext from selected text-like upload files before the browser DLP decision is emitted, improving classifier coverage for upload-heavy workflows without reading arbitrary binary blobs
  • That upload extraction now also covers archive-based office XML formats such as .docx, .docm, .xlsx, .xlsm, .pptx, .pptm, .odt, .ods, and .odp
  • It now also performs bounded PDF literal/hex text recovery plus printable-string recovery for deeper binary uploads such as .pdf, .doc, .xls, and .ppt
  • For explicit download links, can now sample a bounded remote response body when browser fetch/CORS allows it, then run the same redacted classifier path before the download DLP event is emitted
  • Uses the current page's unified Dralvia scan verdict to elevate those browser-time interventions on high-risk or impersonation-heavy pages and writes that reasoning back into the Browser Protection
  • Infers likely personal vs corporate posture from visible page identity context so personal_or_unsanctioned enforcement can work in more real browser sessions without sending raw account emails to the backend
  • Can now also use SaaS governance destination risk (control_action, sanctioned_status, and risk_note) to warn or block browser-time data movement even when the destination did not otherwise match the normal DLP scope
  • Workspace admins can now tune destination-risk scoring in browser DLP policy, including warn/block thresholds, per-rule scores, and whether unknown or unsanctioned apps require a risk note before the extension elevates the action
  • Warned or blocked browser-time DLP prompts now also render a redaction-safe Decision guidance summary for the end user with the dominant trigger, data at risk, and safer allowed path
  • Browser Protection now turns those browser-time decision signals into operator coaching that explains the dominant trigger, data at risk, and safer allowed path without exposing raw sensitive values
  • Can now also consume managed rollout posture hints for unmanaged, BYOD, and contractor contexts so browser-time DLP can elevate the decision even on sanctioned destinations when the session posture is riskier
  • Can now also consume workspace SaaS governance binding metadata (tenant_bound, sso_required) so sanctioned apps can still trigger browser-time intervention when the runtime posture looks personal or mixed
  • When a sanctioned SaaS app defines approved_account_domains, the runtime now treats those domains as corporate identity evidence so approved alias domains do not get misread as personal drift
  • When a sanctioned SaaS app defines approved_account_domains but the current page exposes neither a visible approved account domain nor any inferable workspace, browser-time governance now emits approved_account_domain_unresolved_runtime: it warns by default, and blocks when the app is workspace-bound and already configured for blocking workspace control
  • When a sanctioned SaaS app defines approved_workspace_ids, the runtime can now compare supported workspace/account hints from the URL against that approved list and escalate the wrong workspace/workspace even if the visible account domain is still corporate; supported hints now include modern Slack app.slack.com/client/<team-id> routes, classic Slack workspace subdomains, Google Workspace account-index paths across supported *.google.com apps, Google Admin customer domains from admin.google.com/<customer_domain>/..., Atlassian Administration org ids from admin.atlassian.com/o/<org-id>/..., and GitHub organization or repository-owner routes from github.com/orgs/<org>/..., github.com/organizations/<org>/..., or github.com/<owner>/<repo>/...
  • If explicit approved_workspace_ids exist but the runtime cannot infer any workspace from the current SaaS URL shape, browser-time governance now emits approved_workspace_unresolved_runtime: it warns by default, and blocks when the sanctioned app is workspace-bound and already configured for blocking workspace control, instead of silently downgrading the workspace-binding requirement.
  • The same approved workspace binding can now also count as medium-confidence corporate posture evidence when the page exposes a stable workspace hint but no visible email identity
  • Generates managed Chrome/Edge ExtensionSettings bundles from extension policy state so risky third-party extensions can be blocked or removed centrally
  • Can now sync workspace SWG navigation warn/block rules from the platform rule feed and translate them into local Chrome/Edge declarativeNetRequest rules, plus an optional Firefox webRequest fallback path. Workspace block rules now enforce by default, workspace monitor rules compile to warn, and operators can preview the exact compiled rule feed in Web Access Protection before rollout. Workspace browser policy or managed/local extension config can still set swg_navigation_enforcement=false / swgNavigationEnforcement=false to keep a workspace in dry-run.
  • Those browser navigation rules can also stay scoped to a path prefix, so a workspace can block https://wiki.example/admin without denying the full wiki.example host.
  • When SWG navigation enforcement is enabled, blocked page loads redirect to #/blocked and warn page loads redirect to #/warn, where the extension records a server-resolved Browser Security event and renders workspace why this happened without trusting coaching text from URL parameters.
  • Publishes release metadata, checksum, and optional detached signature artifacts so rollout teams can verify the extension ZIP before manual distribution
  • Can enroll to a workspace automatically and feed shadow-browsing / pre-sign preview workflows when those surfaces are enabled
  • Feeds the shared Browser Protection at #/browser-security so operators can review normalized browser activity in one place

Deployment model​

  • Workspace‑controlled distribution (Chrome/Edge packaging)
  • One‑time install for end users
  • Workspace admins can review beacon history

Install methods​

Two install paths are live today, plus a third once the public listing is published:

  • Self‑hosted download: download the signed extension ZIP from Browser Extension Downloads (#/browser-extension-downloads) and load it, verifying the checksum/signature.
  • Enterprise force‑install (recommended for fleets): push the extension via your browser's enterprise policy (Chrome/Edge ExtensionInstallForcelist) using the force‑install list emitted by the downloads console.
  • Chrome Web Store (one‑click): when the public listing is published, a Chrome Web Store button appears in the downloads console for one‑click install. It is hidden until the workspace's runtime config has the listing URL set, so you only ever see it when one‑click install is actually available.

What it does not do yet​

  • It can now emit managed Chrome/Edge policy bundles for third-party extension block/remove governance, and it can publish Dralvia force-install list values once a stable extension ID + update URL are configured. The actual CRX/store-hosted channel is still a prerequisite for true force-install rollout.
  • Homepage claims alone are not treated as the strongest publisher signal. Store-signed or publisher-aligned update channels score more favorably than a trusted homepage without update-channel evidence.
  • Browser-time data-movement controls now exist for selected actions, scan-aware escalation is live for high-risk or impersonation-heavy pages, workspace-tunable destination-risk scoring is live for SaaS governance signals, adaptive unmanaged / BYOD / contractor controls are available for managed rollouts, workspace custom regex classifiers are now supported, sanctioned SaaS binding rules can now elevate decisions for personal/mixed runtime posture, end-user warn/block prompts now explain the dominant trigger plus safer path, upload extraction now includes OOXML/ODF office archives plus bounded PDF literal/hex and legacy-office string recovery, and explicit download clicks can be sampled when the response is fetchable. Runtime account-posture inference is still heuristic rather than guaranteed, and download/PDF inspection remains bounded rather than guaranteed full-body or OCR/font-aware parsing.

Limits​

Browser-time DLP can block selected data-movement actions when workspace policy is enabled. SWG navigation enforcement now follows workspace block rules by default, compiles workspace monitor rows to warn-mode interstitials, and keeps an explicit dry-run opt-out through workspace browser policy or managed extension config. The warn/block interstitials, Browser Protection enforcement strip, and Web Access Protection compiled-rule preview are available for rollout validation.

Incognito / private browsing​

Browsers disable extensions in incognito (private) windows by default, so without an extra step the extension does not run there and navigation blocks and DLP controls do not apply in incognito. This is a browser rule, not a Dralvia setting: an extension cannot turn itself on in incognito.

The extension is declared incognito-capable, so once it is allowed it behaves the same as in a normal window. To get coverage in incognito, use one of:

  • Per user: open the browser's extensions page, open the Dralvia extension details, and enable Allow in incognito.
  • Managed rollout (recommended): force-install the extension through your browser's enterprise policy and allow it in incognito, or turn private browsing off entirely (for example Chrome's IncognitoModeAvailability = Disabled) so there is no uncovered path.

Until one of those is in place, treat incognito as out of coverage.