How Sextant handles data

Generated — do not edit by hand. Rendered from src/shared/trust-facts.ts, permission-explanations.ts, data-inventory.ts and local-data.ts by npm run docs:data-handling. A test fails when this file and the code disagree, so what follows describes the code as it is, not as someone remembered it.

This is the precise, checkable companion to the privacy policy. It is written for anyone who wants to verify what Sextant does rather than take it on trust: a security reviewer, an administrator deciding whether to allow the extension, or a user who wants the details.

1. What Sextant says about itself, and how each statement is known

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

How it is known: 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.

How it is known: 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.

How it is known: 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.

How it is known: 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.

How it is known: 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.

How it is known: 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

2. Permissions

Every permission in the extension's manifest, what it is for, and what it does not do. A test fails if the manifest gains or loses a permission without this list changing with it.

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: Does not sync anything to your Google account and does not send what it keeps anywhere.

Without it: Sextant would remember nothing and re-read every org on every page.

unlimitedStorage

A large org's metadata can exceed the browser's default storage limit for an extension.

Does not: Does not give Sextant access to any storage outside its own, or to other sites' data.

Without it: On a large org the saved index fails to write, and Sextant cannot finish reading the org.

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.

Does not: 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.

Without it: The toolbar menu could not tell which org a Salesforce Setup page belongs to, and would treat it as a page outside Salesforce.

cookies

Reads your Salesforce session cookie for your org's API address when Sextant calls Salesforce as you.

Does not: Reads one cookie, only for Salesforce addresses, and never stores, logs or exports it. It cannot read cookies of any other site.

Without it: Sextant cannot read from or write to Salesforce at all.

alarms

Resumes a long read of a large org after the browser pauses Sextant's background process.

Does not: Does not run while the browser is closed and schedules nothing outside Sextant.

Without it: A full read of a large org would stop every time the browser paused the worker.

https://*.lightning.force.com/*

Salesforce Lightning pages — the only pages where Sextant shows what a label is and edits translations in place.

Does not: Sextant reads label text on these pages, inside your browser, to identify it. It does not send page content anywhere.

Without it: The hover inspector and Translation Mode could not run.

Install warning it contributes to (paraphrased): Read and change your data on the listed Salesforce sites.

https://*.my.salesforce.com/*

Your org's API address. Sextant calls Salesforce's own APIs there, as you, with the session you already have.

Does not: Each request goes only to the org whose session it uses.

Without it: Sextant could not read metadata or save translations.

Install warning it contributes to (paraphrased): Read and change your data on the listed Salesforce sites.

3. What Sextant stores

Everything is in chrome.storage.local — the browser's storage for this extension, in this browser profile, on this computer. Sextant uses no other storage: no sync storage (nothing reaches a Google account), no cookies of its own, no web storage, no IndexedDB, no files of its own. Nothing listed here is sent anywhere by Sextant. It stays when the browser restarts and when you sign out of Salesforce. Uninstalling the extension deletes all of it; Settings → Privacy & security shows its size and deletes it selectively.

Sextant does not encrypt this data beyond what the operating system and the browser profile provide.

Who is shown what is stored

What Sextant reads from Salesforce is what ONE Salesforce user's permissions allowed, so it belongs to that user, not to the browser profile. Before Sextant shows or uses anything it has stored for an org, it asks Salesforce who is signed in to that org now (getUserInfo(), which needs no permission), and what is stored is shown only to the user it was read for:

• A different Salesforce user signs in to the same org in the same browser profile. Everything Sextant had stored for that org is set aside under the previous user's id before anything is shown or read, and the new user starts from what is theirs, or from nothing. Nobody inherits in either direction: a restricted user never sees what an administrator's session read, and an administrator never inherits a restricted user's narrower view. What was set aside is handed back, untouched, when its user signs in again.
• Nobody is signed in to the org, or Salesforce cannot confirm who is. Nothing stored for that org is shown. It stays on the computer, as the paragraph above says; it is simply not displayed until somebody it belongs to is signed in.
• The same user loses a permission. When Salesforce then REFUSES a read — an object, or the Custom Labels — Sextant removes what it had stored for that part instead of continuing to show it, and stops describing its copy of the org as complete. A field that is merely hidden from the user is not refused: it is simply missing from Salesforce's answer. What an earlier read stored for such a field — read by the same user, while they could see it — stays until the org is read whole again, which you start from Sextant.
• Data stored by a version that did not record who read it. It is shown to nobody. What Salesforce can provide again is removed and read again for whoever is signed in; the rest waits, unseen, until it is deleted.

The session itself is never stored: who is signed in is held in the extension's memory only, and asked again every time the extension's background process starts. The tables below say, per key, who may be shown it. Your preferences and the list of orgs carry no org metadata and belong to the browser profile.

Settings and preferences

Your Sextant preferences: languages you work in, theme, display size, shortcuts, Activity view options, and the actors you marked as automated users.

• Why: To keep Sextant configured the way you left it.
• How long: Until you change or reset them.
• If deleted: It is gone for good; Salesforce does not keep a copy Sextant could read back.

Orgs you have used

For each Salesforce org Sextant has read: its org id, name, environment and My Domain address; your user id, username and name in it; when you last used it; and which org is active.

• Why: To keep every org's data apart, to show which org you are working in, and to switch between orgs.
• How long: Until you delete it. Updated each time you open that org.
• If deleted: Sextant can read it again from Salesforce.

Org metadata cache

What Sextant has read from each org so it can answer without asking again: component API names and ids, labels and translations in your languages, the org's component list with last-modified dates and names, which APIs the org exposes, read progress and timing.

• Why: To answer hover, search and Activity instantly, and to avoid re-reading a large org on every page.
• How long: Replaced on each read and kept until deleted. Sextant reads it again when needed.
• If deleted: Sextant can read it again from Salesforce.

Activity history and change baselines

What Sextant observed changing in each org over time — which component, when, and who Salesforce reports as its last modifier — your own translation edits, and the baselines used to notice the next change.

• Why: 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.
• How long: 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.
• If deleted: It is gone for good; Salesforce does not keep a copy Sextant could read back.

Translation snapshots

Complete reads of an org's translations, kept so two moments or two orgs can be compared.

• Why: To answer whether translations arrived, and what changed between two reads.
• How long: The most recent snapshots per org; older ones are replaced.
• If deleted: It is gone for good; Salesforce does not keep a copy Sextant could read back.

Deployments

Translation changes you queued or sent — including the values being written — their outcome, deploy notices, and the component lists of deployments Sextant noticed in an org.

• Why: To track a deployment until Salesforce finishes it, even if the browser restarts, and to report what a deployment contained.
• How long: Kept until deleted. A deployment still in progress cannot be deleted until it finishes.
• If deleted: It is gone for good; Salesforce does not keep a copy Sextant could read back.

Workspace

Components you kept, your edits with their before and after values, review marks and the groups you named.

• Why: Your working set, and a package.xml of what you touched.
• How long: Until you remove items or delete the Workspace.
• If deleted: It is gone for good; Salesforce does not keep a copy Sextant could read back.

Diagnostics

Developer diagnostics, only when turned on: detection traces (element text, page address and how Sextant identified it) and the timing record started from the console.

• Why: To investigate a detection or performance problem you chose to capture.
• How long: Bounded: the newest traces and timing marks replace the oldest. Until cleared.
• If deleted: It is gone for good; Salesforce does not keep a copy Sextant could read back.

Data kept for other Salesforce users of this browser

What Sextant read for a different Salesforce user who signed in to the same org in this browser profile: their Activity history, snapshots, deployments and Workspace, and their most recent metadata cache. It is set aside under their user id and is never shown to anyone else.

• Why: 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.
• How long: 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.
• If deleted: It is gone for good; Salesforce does not keep a copy Sextant could read back.

Data from older versions

Keys written by earlier versions of Sextant before their data moved to its current place. Read once for migration.

• Why: Migration only.
• How long: Until migrated or deleted.
• If deleted: Sextant can read it again from Salesforce.

4. Exporting your data

Settings → Privacy & security → Export my Sextant data saves a JSON file (sextant.local-data-export, version 1). The file carries this notice:

A copy of the data Sextant keeps in this browser. It never contains your Salesforce session or any credential. It may contain org metadata, translation text and names of people in your orgs: share it only as you would share that.

Never exported: readerVault::…, privacyDeletionNotice, and any key this version of Sextant does not recognise. The file lists by name what it left out. Credential-shaped text found inside an exported value (a session id, a bearer token, an API key) is replaced with [redacted].

The file holds what you could be shown at that moment, and nothing else: for an org you are not signed in to, or whose stored data was read by another Salesforce user, that org's data is left out of every value, and what is set aside for other users is never exported.

5. Deleting your data

Settings → Privacy & security. Every deletion asks first, removes only Sextant's data in this browser, and never changes anything in Salesforce. A deletion is about this computer, not about one user: each choice below also removes the matching data that is set aside for other Salesforce users of this browser profile.

• Clear cached org data. Sextant reads your orgs again the next time you use them — usable again in seconds; the rest of a large org follows in the background. Removes: Org metadata cache; Data from older versions.
• Delete history. Activity history, change baselines, snapshots and deployment records. Salesforce cannot give this history back — export Activity first to keep a copy. Removes: Activity history and change baselines; Translation snapshots; Deployments.
• Delete the Workspace. Components you kept, your edits and your groups. Export the Workspace first to keep a copy. Removes: Workspace.
• Delete diagnostics. Detection traces and timing records. Removes: Diagnostics.
• Reset settings. Your preferences return to their defaults. Removes: Settings and preferences.
• Delete one org's data. Everything Sextant keeps about the org you choose: its cache, history, snapshots, deployment records and Workspace items. Other orgs are not touched.
• Delete all Sextant data. Everything listed above, for every org. Sextant starts again as if it had just been installed.

A deletion that would remove the record of a deployment Salesforce is still running is refused until it finishes: A deployment is still running. Wait until Salesforce finishes it, then delete — its record is how Sextant reports the outcome.