Trust Center

What Sextant says about itself

The same six statements Sextant shows in Settings → Privacy & security. Each says how it is known: enforced by the browser, checked by automated tests, or checked on every release build.

• Sextant sends requests only to Salesforce, and the browser blocks its pages from contacting any other site.

  Enforced by the browser · Checked by automated tests · Checked in every release build

  What it does not mean: The browser enforces this for Sextant's own pages and its service worker. The part of Sextant that runs inside the Salesforce page sends nothing to any site itself — it asks the service worker — and that is checked by tests, not enforced by the browser. The browser policy allows any host under my.salesforce.com; the code sends each request only to the API host of the org whose session it uses. It does not describe what Salesforce, the browser or other extensions do.

  Where to check

  • manifest.config.ts — content_security_policy.extension_pages, connect-src 'self' https://*.my.salesforce.com
  • security-qa/csp-enforcement.pw.ts — loads the built extension; requests to other hosts never reach the network
  • src/shared/salesforce-transport.ts — the only function that performs a request; destination checked per request
  • src/security/network-boundary.test.ts — fails if any other module makes a request

• No analytics, telemetry, crash reporting or advertising.

  Enforced by the browser · Checked by automated tests · Checked in every release build

  What it does not mean: The Chrome Web Store shows every publisher aggregate statistics such as install counts, and Chrome itself contacts Google (for example to check for updates). Sextant sends nothing to either.

  Where to check

  • scripts/release/scan-dist.mjs — fails a release whose bundle contains an analytics or telemetry endpoint or SDK
  • src/security/network-boundary.test.ts — no request primitive outside the Salesforce transport
  • manifest.config.ts — the CSP leaves no destination for such data

• There is no Sextant account or server. Nothing you do in Sextant is sent to its developer.

  Enforced by the browser · Part of the release process

  What it does not mean: If you contact the developer (for support or a security report), what you send is received like any message.

  Where to check

  • manifest.config.ts — no host a Sextant server could live on is reachable
  • docs/security/RELEASE_SECURITY.md — adding a backend is a Trust Architecture Change requiring a policy update first

• Everything Sextant runs ships inside the installed extension. It downloads no code.

  Enforced by the browser · Checked by automated tests · Checked in every release build

  What it does not mean: Updates arrive through the Chrome Web Store as a new version of the whole package, and the release process records the SHA-256 of every package it builds. A trusted update could still change what Sextant does; that is why every change to these statements must ship with a matching change to this list.

  Where to check

  • Manifest V3 and manifest.config.ts — script-src 'self', no 'unsafe-eval'
  • security-qa/csp-enforcement.pw.ts — string evaluation is refused in an extension page
  • src/security/code-boundary.test.ts — no eval, Function constructor or HTML injection in the source

• Your Salesforce session is read when a request needs it and is never stored, logged or exported by Sextant.

  Checked by automated tests

  What it does not mean: Sextant uses the session you already have in your browser; signing out of Salesforce ends it.

  Where to check

  • src/background/index.ts — getSessionId: read from the cookie store per request, never written
  • src/security/session-boundary.test.ts — the session value never reaches storage, logs, messages or exports

• What Sextant keeps stays in this browser profile. You can see it, export it and delete it in Settings.

  Checked by automated tests

  What it does not mean: It is not encrypted by Sextant beyond what your operating system and browser profile provide. Anyone with access to this browser profile can read it.

  Where to check

  • src/shared/data-inventory.ts — every stored key, classified; chrome.storage.local only (no sync)
  • src/security/data-inventory.test.ts — fails when code stores a key the inventory does not describe

The questions, answered

What can Sextant access?

Salesforce Lightning pages, to read the text they show and identify it; your org's own API, called as you with the session you already have; and its own storage in your browser profile. The permissions table below names each grant and what it does not do.

Permissions

Every permission the extension asks for, what it is for, and what it does not do.

Permission	Why	What it does not do
storage	Keeps your settings, the orgs you use, what Sextant has read from them, your Workspace and your history in this browser profile.	Does not sync anything to your Google account and does not send what it keeps anywhere.
unlimitedStorage	A large org's metadata can exceed the browser's default storage limit for an extension.	Does not give Sextant access to any storage outside its own, or to other sites' data.
activeTab	Lets Sextant's toolbar menu read the address of the tab you opened it on, so it can name the Salesforce org you are looking at.	Grants nothing for other tabs or later visits, runs no code in the page, and adds no install-time warning. Sextant does not ask for the broader `tabs` permission, which Chrome describes as reading your browsing history.
cookies	Reads your Salesforce session cookie for your org's API address when Sextant calls Salesforce as you.	Reads one cookie, only for Salesforce addresses, and never stores, logs or exports it. It cannot read cookies of any other site.
alarms	Resumes a long read of a large org after the browser pauses Sextant's background process.	Does not run while the browser is closed and schedules nothing outside Sextant.
https://*.lightning.force.com/*	Salesforce Lightning pages — the only pages where Sextant shows what a label is and edits translations in place.	Sextant reads label text on these pages, inside your browser, to identify it. It does not send page content anywhere.
https://*.my.salesforce.com/*	Your org's API address. Sextant calls Salesforce's own APIs there, as you, with the session you already have.	Each request goes only to the org whose session it uses.

What does Sextant store, and where?

Your settings, the orgs you have used, a cache of the metadata it has read, the history of changes it observed, translation snapshots, the deployments you queued, your Workspace and — only if you turn them on — developer diagnostics. All of it in chrome.storage.local, in your browser profile, on your computer. Nothing is synced to a Google account.

What Sextant keeps

Each kind of data Sextant stores in your browser profile, why, and for how long — the same list Settings → Privacy & security shows, generated from the code that does the storing.

Data	Why it is kept	How long
Settings and preferences	To keep Sextant configured the way you left it.	Until you change or reset them.
Orgs you have used	To keep every org's data apart, to show which org you are working in, and to switch between orgs.	Until you delete it. Updated each time you open that org.
Org metadata cache	To answer hover, search and Activity instantly, and to avoid re-reading a large org on every page.	Replaced on each read and kept until deleted. Sextant reads it again when needed.
Activity history and change baselines	To show what changed and what was yours. Salesforce does not provide an equivalent value-change history that Sextant can reconstruct later, so Sextant keeps what it observes.	The last 30 days of what Sextant has observed in each org, and at most 3,000 events or 2 MB of them; older events are removed automatically. Turning on extended local history in Settings keeps about 180 days instead, still bounded. Baselines are replaced as the org is read.
Translation snapshots	To answer whether translations arrived, and what changed between two reads.	The most recent snapshots per org; older ones are replaced.
Deployments	To track a deployment until Salesforce finishes it, even if the browser restarts, and to report what a deployment contained.	Kept until deleted. A deployment still in progress cannot be deleted until it finishes.
Workspace	Your working set, and a package.xml of what you touched.	Until you remove items or delete the Workspace.
Diagnostics	To investigate a detection or performance problem you chose to capture.	Bounded: the newest traces and timing marks replace the oldest. Until cleared.
Data kept for other Salesforce users of this browser	What Sextant reads is what one Salesforce user's permissions allow, so it is never shown to another user — and signing in as somebody else must not destroy a colleague's history, which Salesforce cannot give back. It is handed back to them, untouched, when they sign in again.	Until that user signs in again, or until it is deleted here. The metadata cache is kept for one previous user per org; a third user replaces it. Data stored before Sextant recorded who read it is never shown to anyone: what Salesforce can provide again is removed, the rest waits here until deleted.
Data from older versions	Migration only.	Until migrated or deleted.

Every stored key, its source and what an export contains: How data is handled.

Does anything leave the browser?

Requests to your Salesforce org, and — only when you ask — the translation changes you save or deploy. The browser's own content security policy forbids Sextant's pages and service worker from contacting any other site; the part of Sextant that runs inside Salesforce pages makes no requests at all.

Does Sextant collect telemetry?

No. No analytics, telemetry, crash reporting or advertising, and every release build is scanned for analytics endpoints and SDKs before it can ship.

Does Sextant have a backend or an account?

No. There is no Sextant server and no account. Nothing you do in Sextant reaches its developer; adding a server would be a Trust Architecture Change that must be disclosed here, in the privacy policy and in the store listing before it ships.

How does authentication work?

Sextant uses the Salesforce session you already have in your browser. Its background process reads the org's session cookie when a request needs it and sends it only to that org's API address. The session is never stored, logged or exported, and you are never asked for a password.

How are updates delivered?

Through the Chrome Web Store, as a new version of the whole package. Sextant downloads no code at runtime: its content security policy forbids remote scripts and string evaluation, and a release build that contained either would fail its own scan.

How are releases validated?

One script builds every release from a tagged commit in a clean checkout, and stops on the first failing gate: type checks, the full test suite, a leak scan, a reproducible build, a scan of the built package, the content security policy enforced in a real browser, a software bill of materials, a deterministic package with its SHA-256, and a diff of everything trust-relevant against the approved baseline. The release process page has the list.

Release process · Threat model

How can local data be deleted?

In Settings → Privacy & security: see how much each kind of data uses, export it (never including your session or any credential) and delete it — the cache, the history, the Workspace, diagnostics, settings, one org's data or everything. Deleting there never changes anything in Salesforce. Uninstalling removes all of it.

What changes would require updated disclosures?

A server, an account, analytics, an AI provider, a new permission or host, a new destination, remote code, or a new category of stored data. Each is a Trust Architecture Change: the release that contains one is classified security-sensitive, needs explicit approval, and must update this page, the privacy policy, the data-handling document and the store listing in the same release.

Reporting a security problem

Please do not report security problems in public. How to report one, what is in scope and what happens next are in the security policy. Security policy

Private reporting channel: security@usesextant.dev