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.

Without an account​

From version 1.1.0 the extension works on its own, free, with no account:

  • Risky pages get a warning. An Avoid page is covered by a warning with the strongest reasons behind the verdict, a Leave site button, and a link to the full result on dralvia.tech. A Caution page gets a small card in the corner and stays usable.
  • What it sends: for the automatic check, the site and path of the page only, for example https://shop.example.com/checkout. Never the part after ? or #, where sign-in codes and reset links usually are. When you open the extension and ask it to check the page, it sends the full address, because you asked.
  • Incognito and private windows are not checked automatically. An organisation can turn that on with the autoScanInIncognito managed policy.
  • Answers are reused for up to 24 hours (6 hours for Caution or Avoid), so revisiting a page does not send it again.
  • Checks made without an account stay private. They are not shown to other visitors or listed in public scan feeds.
  • Known limit: the first check of a site nobody has scanned recently takes up to about 30 seconds, so the warning can appear after the page has loaded.

Enrolling the extension in a workspace (Starter plan and above, including the Starter trial) adds everything below. In a free workspace it stays in the mode above. The full privacy statement is at marketing.dralvia.tech/privacy/extension.

Wallet guard​

From version 1.1.1 the extension checks wallet requests that a page sends to a browser wallet (MetaMask and other wallets that use the standard window.ethereum or EIP-6963 connection), before the wallet shows them to you.

On your device, with or without an account (nothing is sent):

  • an approval that lets someone spend an unlimited amount of a token;
  • a signature permit (EIP-2612 Permit or Uniswap Permit2) that lets someone move a token without another prompt;
  • a request to give one contract every NFT in a collection (setApprovalForAll);
  • a marketplace order (OpenSea Seaport, including bulk orders, or Blur) that gives away items from your wallet and pays you nothing, sends most of the payment to someone else, or offers any token of a collection; a Blur sell order at price 0; a Blur bulk signature, whose orders are hidden behind a hash (from version 1.1.2);
  • a Permit2 batch or signature transfer, which can let someone take several tokens, or take a token at once, with one signature; a DAI-style permit that grants unlimited spending (from version 1.1.2);
  • a request to sign a raw hash (eth_sign), which can authorise anything;
  • a request to hand your account to a contract (EIP-7702 authorisation);
  • the same requests inside a batch (wallet_sendCalls).

You see what was found and choose Block or Continue. Block rejects the request the same way the wallet's own Reject button does (EIP-1193 code 4001), so the page sees a normal rejection and the wallet never shows it.

In a workspace with wallet warnings on (the pre-sign setting), each transaction and permit is also checked by the workspace's wallet review: the target contract, the spender, and Dralvia's known-bad address lists. A block answer opens the same dialog; a review answer shows a small notice. A plain payment to an ordinary wallet is interrupted only when the review says block. Only the request needed for the check is sent: the chain, the target address, the call data, the sender and the amount.

The wallet review runs on Ethereum, Binance Smart Chain, Polygon, Arbitrum, Optimism, Base and Avalanche, and from version 1.1.3 also on Sonic, Linea, zkSync, Scroll and Fantom. On any other chain the extension still runs the checks on your device, but the request is not sent for review.

Limits:

  • Only a real click counts: a page cannot press Continue for you from a script.
  • The guard runs inside the page, so a page written specifically to get around Dralvia can reach the wallet another way. The wallet's own confirmation screen still applies.
  • Marketplace orders are checked on the device only (what you give, and what comes back to you). Whether the price is fair is not checked, and other marketplaces' order formats are not read yet.
  • Older wallet calls (send, sendAsync) are not checked.

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.