Privacy architecture

Who this is for: anyone deciding whether to trust Attest with their Gmail and Calendar, and anyone changing what Attest stores: reviewers, contributors, the privacy and security reviews. What you’ll know after: what leaves the browser (nothing, unless you turn on an option that sends), what each observer reads and what it keeps, every ledger table and field, what each stored fact means, what is hashed and what that does and does not hide, how long things are kept, what the export holds, what the optional model sees and where it runs, and what the opt-in usage numbers send.

Status: v3.1 (the Sprint 6 close: the ledger in a storage bucket of its own, rebuilt into the next one and deleted whole, §12; v3 was Sprint 6, task 6.5, encryption at rest; v2 Sprint 5, task 5.9; v1 Sprint 2, task 2.9). It describes Attest 0.1.0: the Gmail and Calendar readers, pasted agent activity logs (the agent readers are off, §1), grading, the options page, the optional model (§10) and the opt-in usage numbers (§11). With both of those off, the extension makes no network request at all. The store-facing summary is PRIVACY.md.

Contents

1. What leaves the browser
2. What Attest cannot hide
3. What is read, and what is kept
4. The policy allowlists: every allowlisted field, per source
5. Every ledger table and field
6. What is hashed
7. Retention and purge
8. The export
9. Logs
10. The optional model: what it sees, where it runs, your own key
11. Anonymous usage numbers: what is sent, where, how often, how to stop, with a real payload
12. Encryption at rest: optional; what it seals, where the key lives, what it does and does not protect

1. What leaves the browser

Nothing, unless you turn on your own model key or the anonymous usage numbers (below). Attest has no account and no remote code (Hard Rules 1, 9).

• No network allowlist. NETWORK_ALLOWLIST in extension/src/config-network.ts is empty: no host may be contacted whatever you chose. allowedHosts adds exactly one host for each option you turn on: the telemetry host while the usage numbers are on, the model company’s while your own key is on. With both off it is empty.
• Anonymous usage numbers, off unless you turn them on (since Sprint 5.7). Turned on in the options page’s Privacy section, the service worker sends one payload a day, about the day before, to the one telemetry host (TELEMETRY_HOST), and records the day so it never goes twice (src/telemetry/send.ts). The payload is counts, yes-or-no values, enum words, the install id, the versions and the date, and its schema allows no other string (src/telemetry/schema.ts, held equal to the server’s). The options page shows exactly what the next send holds. From every install’s reports, the server publishes totals one closed month at a time, never one install’s. The host is attest-production-5149.up.railway.app, the API deployed on Railway on 2026-10-13; a store build refuses any other, or a privacy policy that does not name it. §11 describes it in full, with a payload the real builder made.
• Two host permissions, both read-only. The manifest (extension/wxt.config.ts) asks for https://mail.google.com/* and https://calendar.google.com/*, so the content scripts can read those pages in tabs the user opened, plus storage, alarms, scripting (since Sprint 4.5: the readers’ content scripts are registered at runtime, so one you turn off is unregistered; it reaches no other host), notifications (since Sprint 4.6: an alert when a receipt ends NOT_FOUND, UNASKED or OVER_SCOPE, shown on this device by Chrome and your operating system, naming no counterparty, amount or subject: §5.15) and sidePanel (the build adds the last one for the side panel). No AI agent’s site is asked for: Meta’s, OpenAI’s and Anthropic’s terms forbid collecting data from their sites by automated means, so those readers are off (AGENT_READERS in extension/src/config-agents.ts; Decisions [3.10]). Attest never fetches from those hosts or any other: no Gmail API, no OAuth, no background tab. The one tab Attest may open is your Gmail Sent folder, pinned and in front of you, and only if you turn on Check Gmail for me (§3); it needs no tabs permission, and the manifest has none.
• Your own model key, off unless you turn it on (since Sprint 5.4). With an Anthropic or OpenAI key saved and turned on in the options page’s Model section, and Chrome’s on-device model not on and ready, Attest asks that company’s official endpoint (api.anthropic.com or api.openai.com, nothing else) about each claim still checking with a partial match: the claim’s kind, counterparty, short subject, amount and time; and the same for the one sent email, event or receipt it partly matched, with Attest’s id for it and, for a purchase, the merchant (src/intel/input.ts), with your key in the request’s header. Never a page, never what you asked an agent. The company keeps what it receives under its own terms. Each claim is asked once (§5.17); the answer can only move a partial match toward verified (docs/grading.md §5.4). Chrome’s on-device model, when on, runs on this computer and sends nothing. §10 has what each sees and where it runs.
• A test enforces it. extension/tests/e2e/network-intercept.spec.ts (@mandatory) loads the built extension, opens the Gmail Sent, receipt and Calendar fixtures with the shipped content scripts running, reloads them for five minutes, and fails on any request from the extension outside the allowlist. Its negative control proves it catches a request from the service worker, an extension page and a page.
• A second test hunts for leaks. extension/tests/e2e/no-leak.spec.ts (@mandatory) plants three known secrets in the fixture pages (in message bodies, snippets, event locations) and checks that none reaches the ledger export, IndexedDB, extension storage, the console or the network.

2. What Attest cannot hide

Limitations first.

• The ledger is encrypted only if you turn encryption on. It is an IndexedDB database in your Chrome profile on disk. Other websites and other extensions cannot read it (it belongs to Attest’s own origin), but anyone or anything that can read your Chrome profile can, unless you turn on encryption at rest in the options page (§12). Even then, ids, hashes, dates, action types, grades and states stay readable, because Attest finds its records by them; and anyone using this browser while Attest is unlocked sees what you see.
• A hash is not a secret. Attest stores some values only as SHA-256 hashes (§6), so a casual reader of the ledger or an export does not see them. A hash of a value someone can guess (an email address, a calendar named “Family”) can be confirmed by hashing the guess. Hashing hides; it does not encrypt.
• Some content is stored in clear, because matching needs it. A recipient address, a merchant name, an amount, the first 80 characters of a subject, and for Calendar the first guest address of every event in a range you looked at; its other guests are kept only as one-way keys (§5.4). These are the facts a claim is checked against.
• The export holds everything the ledger holds (§8). Treat an export file like the ledger itself.
• The content script sees the whole page. It runs inside the Gmail or Calendar tab you opened, so the page’s text is in its memory while a pass reads it, as it is in Gmail’s own. What it keeps from a pass is only what this document lists; the rest is dropped before anything crosses to the service worker (Hard Rule 2).

3. What is read, and what is kept

Each observer reads one vendor page in a tab you opened, and only while you have it open (Hard Rule 11), with one exception you choose: Check Gmail for me, below. How each one reads its page is in docs/adapters.md §8.

A pasted activity log (Sprint 3.13). The side panel reads the text you paste in the panel itself (paste.ts) and sends the service worker only the claims it found (the fields of §5.8) and the minutes the log names (§5.11); the text is dropped when the preview closes, and is never stored, logged or sent. The paste box has spell check off, so Chrome’s enhanced spell check never sends it to Google.

Away detection (Sprint 3.14, off unless you turn it on in the options page). With the optional idle permission, Chrome tells the service worker when you go away (no input for a minute, or the screen locked) and when you are back; the ledger keeps the start and end of each time away (§5.11) and nothing else. Turning it off gives the permission back and deletes every interval.

Auto-check Gmail (Sprint 4.9; “Check Gmail for me” in the options page’s Adapters, off unless you turn it on; flag ATTEST_AUTO_CHECK_GMAIL). This is the one exception to Hard Rule 11: the one time Attest opens a page itself. When it is on and the Gmail reader is on, after each grading batch (every 5 minutes) the service worker looks for an email.sent claim whose receipt has been PENDING, with no mark of yours, for half its grace (graceMin / 2, 15 minutes in the shipped policy) since Attest read it, while no Gmail tab has shown Attest your Sent folder since then (no gmail.sent coverage ping synced after the claim was read). Then it opens https://mail.google.com/mail/u/0/#sent in one new tab, pinned and active in the window you are using: never in the background. It waits, trying again at the next batch, while Chrome’s last focused window does not have the focus (another app is in front, the screen is locked) or is minimised, and, while away detection is on, while Chrome says you are idle or the screen is locked (security review SEC-2). The Gmail reader reads that tab as it reads any Gmail tab you open, and never acts on it (Hard Rule 3). One tab serves every claim due at that moment; after it, no tab opens for graceMin (30 minutes), and a claim that was due when a tab opened never opens another, so each claim opens at most one. The popup says why the tab opened, for whose claims, until that 30 minutes ends; the ledger keeps when, until when, how many claims and whose (§5.6), written only after the tab opened. chrome.tabs.create with a URL and chrome.windows.getLastFocused need no permission: the manifest has no tabs permission (src/background/auto-check.ts; extension/tests/e2e/auto-check.spec.ts runs it on the built extension, off and on).

Attest does not run in incognito windows (the manifest says "incognito": "not_allowed"): an incognito Gmail or Calendar tab is never read, so nothing from it reaches the ledger, which lives in your regular profile and outlives the incognito session.

Every observer also reads the signed-in account’s address, and keeps only its hash (§6). While a tab is open, the observer notes the instant of your last key press, pointer move, scroll or touch in it (never which key, where, or on what), and sends one yes/no with each coverage ping: whether there was input in the last minute (§5.3).

The route from page to disk has two checks. In the content script, redact.project() (src/core/redact.ts) builds each row from the fields the policy allows for its source and nothing else. In the service worker, upsertObservation() refuses any row project() could not have returned: a field outside the allowlist, a self-chosen contentHash, a sightedAt (docs/grading.md §10). Every message on the way is a strict Zod schema, so an extra field is an error, not a passenger (docs/adapters.md §9).

4. The policy allowlists

allowlistedFields in policy/default.json names, for each observation source, the only fields a row of that source may store. Six are content fields a page supplies (counterparty, merchant, amountCents, currency, subjectHint, occurredAt). Two are derived markers the code computes, never copies from the page (rowKeyHash, contentHash). occurredAt is required in every list. The fields every row has whatever its source (id, source, type, observedAt, sightedAt) are computed by project() or the ledger and are never in an allowlist (§5.1).

pnpm check-docs (scripts/check-docs-allowlist.ts) fails when a field the policy allowlists has no row below, or a row below names a field the policy does not allowlist.

4.1 Allowlist: gmail.sent

4.2 Allowlist: gmail.receipt

4.3 Allowlist: gcal.event

5. Every ledger table and field

The ledger is one IndexedDB database, attest, in a storage bucket of its own (ledger- and a number, since the Sprint 6 close; §12, Chrome’s own copies), opened through Dexie only inside extension/src/ledger/ (db.ts, schema version 11 in migrations.ts). Every row is written through a strict Zod schema and read back through one: a row that fails is skipped (logged by id only) and never shown. Some tables add derived index fields to each row so IndexedDB can answer range queries; they are computed from the row’s own fields, stripped on every read, and never exported (index-fields.ts). With encryption at rest on (§12), a row of the nine tables that hold content is stored as the fields IndexedDB keys and indexes it by, its index fields, and sealed, every other field below sealed together; it reads back exactly as listed.

Outside IndexedDB, chrome.storage.local holds at most four keys, and since Sprint 5.3 only Attest’s own pages and service worker can read it, never a content script (setAccessLevel TRUSTED_CONTEXTS, set at every start of the service worker, src/background/byo.ts): attest.installId (a random version-4 UUID, install-id.ts; it identifies nothing about you, is never logged, and only the opt-in usage numbers use it, §11); and, only while you have saved your own model key, attest.byoKey, the key, and attest.byoVendor, its company (§10): never logged, never in the ledger, so never in an export, and deleted by Forget my key and by Delete all data. While encryption at rest is on, the key is kept sealed under the ledger’s key (§12). And attest.ledgerBucket, from the Sprint 6 close, the name of the storage bucket the ledger is in, ledger- and a number, which says nothing about you (§12; src/ledger/place.ts). Your choices about what Attest may read or open, the page readers you turned off and the flags you set, are kept in the ledger’s meta (§5.6; src/ledger/consent.ts), where no script on a Gmail or Calendar page can reach them. Sprints 4.5 and 4.9 kept them in chrome.storage.local (attest.readersOff, attest.flags), which content scripts can write; an update moves them into the ledger once and removes those keys (src/background/consent-move.ts; security review SEC-3). A reader that is off has no content script registered, so a page you open is not read, and what a tab opened before sends is not stored. chrome.storage.session (memory Chrome empties when the browser closes, which no content script can read: Chrome’s default for this area, which Attest never widens) holds at most four keys: attest.idleSession, while away detection is on, true once this browser session has started watching, so a time away that the previous session left open is closed at what was confirmed, never stretched over the next day (src/background/idle.ts); and attest.openReceipt, from Sprint 4.6, the id of the receipt a clicked alert asked the side panel to open (src/background/alerts.ts); and attest.ledgerKeys, from Sprint 6.5, while encryption at rest is on and the ledger is unlocked: the key its rows are sealed with, derived from your passphrase (during a passphrase change, the one before as well), which the service worker writes when you unlock and clears at its every start, so Attest’s pages read the ledger without waking it, and a restart of the service worker locks it (§12; src/crypto/session.ts). It is kept in memory, never in the profile, never logged and never exported. And attest.ledgerRebuild, from the Sprint 6 close, true only while the service worker rebuilds the ledger into its next storage bucket after a job sealed every row, so Attest’s pages wait to read until the rows are there (§12; src/ledger/rebuild-mark.ts).

5.1 observations

What the observers saw: one row per distinct fact. Written only by the service worker, only through upsertObservation. Key id; contentHash is unique.

Index field: timeBucket (the hour of occurredAt). Schema v4 dropped the v1 counterpartyTokens index and removed its field from every stored row (src/ledger/migrations.ts).

5.2 coverageIntervals

What each observer saw, and when: the spans grading reads to tell “not there” from “not looked at” (Hard Rule 5). One row per merged interval; a pass that overlaps or touches a stored interval of the same group (observer, source, account, allCalendars, changesSince, and first-look marker or not) is merged into it.

It also holds first-look markers (src/ledger/first-look.ts): for each Calendar event stored as a first sighting (an event a pass could not compare with an earlier view, or a change it noticed too late to say when it happened), one entry whose window is the event’s start instant, with the observer id, the account hash (none for a page without one), allCalendars, and the sighting instant as both lastSyncAt and changesSince. No new field: the start instant is already in the event’s observation row. A marker keeps an event that was already there from ever reading as something an agent did (docs/grading.md §7).

The scroll-depth limit. A Gmail Sent window reaches back only as far as the rows Gmail draws at the head of the list: 50 by default, 100 at Gmail’s largest page. It starts a minute after the oldest row drawn, since the list may go on (docs/grading.md §3), and an older page of the list gives rows but never a window. So a send older than the head’s oldest row is outside every window from then on, and a claim about it is UNVERIFIABLE, never NOT FOUND: an agent that sends fifty emails after a false claim pushes the claim’s minute off the head and out of NOT FOUND’s reach. Measured by the red team’s observer starvation (docs/attacks-that-work.md).

When the computer’s clock goes back (a jump forward that came back, or a step back), the service worker deletes every interval and marker synced after the clock’s new time, before it stores anything else (src/ledger/clock-guard.ts): a span stamped by a clock that was ahead never vouches for anything.

Index fields: accountKey (the account hash, or empty), startMs, endMs, syncMs (the instants in epoch milliseconds), kind (point for a single instant, span otherwise) and lenMs (endMs − startMs), which let a read stop at the intervals that can reach the window it asks about. They hold nothing the stored fields do not.

5.3 coverage

The latest coverage ping of each observer and account, as the observer posted it. Key [observerId+accountKey].

Index field: accountKey. A latest ping synced after the clock’s time is deleted when the clock goes back (§5.2).

5.4 calendarSnapshots

For each Calendar observer, account and visible range, the last snapshot of that range: what the service worker compares the next pass with, to find created, changed and deleted events. Key [observerId+accountHash+range]. A snapshot is stored only for a page whose account is known.

This table holds more than an observation’s allowlist. It keeps every event in a range you looked at, whether or not anything happened to it, with its end and all-day flag, its first guest’s address (a deletion’s row names it) and, for each of up to 200 guests, only a one-way key: SHA-256 of the address, ASCII-lowercased, enough to tell that the guest list changed, never who is on it. It is not governed by allowlistedFields, which covers observation rows; it is governed by its own strict schema (src/observers/gcal/snapshot.ts, src/ledger/calendar-snapshots.ts). It is needed because a deletion can only be seen by comparing with what was there, and a changed guest list is an update.

The snapshot’s own fields:

Index field: readMs (readAt in epoch milliseconds, for the purge). A record read after the clock’s time is deleted when the clock goes back (§5.2), so its range is compared with nothing next time.

5.5 adapterHealth

The latest health of each observer (and of an agent adapter, taken only from its own site, once its reader may run): what the popup’s banner will show (Hard Rule 6). Key adapterId.

5.6 meta

Small facts about the ledger itself. Key key.

5.7 requests

Empty until Sprint 3: what you asked an agent, read from the agent’s own page. Key id.

Index field: date (the local date of ts).

5.8 claims

What an agent says it did, read from an activity log you paste into the side panel (since Sprint 3.13; the readers of the agents’ own pages are off, Decisions.md [3.10]). Key id; rawHash is unique.

Index field: date.

5.9 grants

What you allow each agent to do. Until the options page lets you declare it (Sprint 4), the service worker writes a default grant for each of the four agents before it stores your first import: every action type, no allowlist, no spending limit and no declared access, so your first receipts are grades rather than all OVER SCOPE (default-grants.ts). It never replaces a grant you set. Key agent.

5.10 receipts

Written by the grading batch since Sprint 3.13: the grade for each claim, each unclaimed action, each undeclared permission. Key id. A receipt holds ids, hashes, codes and numbers; the only free text in it is the reason you type when you override a grade.

Index fields: date (the local date of computedAt) and computedMs (computedAt in epoch milliseconds, schema v8), so the popup and the side panel read the newest receipts a page at a time (src/ledger/views.ts). They hold nothing the stored fields do not.

5.11 activity

Since Sprint 3.14 (schema version 6): when an agent’s own log says it worked, and, only if you turn on away detection, when you were away (activity.ts). Read by the grading batch to say “likely” with evidence (docs/grading.md §7). Instants and an agent id only. Key id.

Index fields: startMs, endMs.

5.12 receiptInputs

Since Sprint 3.13 (schema version 5): what each receipt was graded with besides its claim and evidence, so pnpm attest replay can grade it again from an export and prove it (replay-records.ts; docs/grading.md §9). Written only by a grading batch, beside the receipt; deleted when the receipt is graded again, deleted or purged. Key inputsHash. Derived data only: the fields below are copies of what other tables already hold, and none is content.

Index field: none (policyHash and coverageHash are indexed as stored, so a policy or a coverage no input names any more is found and deleted).

5.13 policies

Since Sprint 3.13: each policy document a receipt was graded under, as policy/default.json writes it, so replay grades with exactly that policy. Thresholds, windows, weights and rules; no data of yours. Key policyHash; deleted once no stored input names it.

5.14 batchCoverages

Since schema version 7 (the Sprint 3 close): the coverage a grading batch graded with, once per batch, named by the receipts’ inputs (§5.12). Before, every receipt’s inputs held its own copy: with many Calendar events in view a copy was tens of kilobytes, written again for each receipt still checking at every batch. Key coverageHash; deleted once no stored input names it. Derived data only: instants, sources and account hashes, never content.

5.15 alerts

Since schema version 9 (Sprint 4.6): one row per receipt that alerts, keyed by the receipt’s id, so a receipt alerts once, ever (src/ledger/alerts.ts). A grading batch adds a row, pending, for each receipt it made FINAL as NOT_FOUND, UNASKED or OVER_SCOPE; the service worker then settles it for good before it asks Chrome for a notification. A notification names the grade, the agent and the action with its time (“Not found: Muse”, “Muse said it created a calendar event at 14:00. Attest found no sign of it.”), never a counterparty, an amount or a subject, because it can show on a locked screen; it is shown by Chrome and your operating system, on this device. Deleted with its receipt by the purge (§7). Ids, an agent, a grade, a state and two instants only.

5.16 digests

Since schema version 10 (Sprint 4.7): one weekly digest per week, keyed by the week’s Monday, made by the service worker on Monday at 09:00 from what the ledger holds for the week before (src/ledger/digest.ts), and kept so earlier weeks can be read again. The digest page (extension/entrypoints/digest/) shows it and computes nothing. Its share is markdown made from it alone (src/ui/digest-share.ts), and a digest keeps no address, so a share cannot hold one: a counterparty is its domain, taken from an address only, and a subject only its hint, with any address in it written as its domain. It also keeps your marks on the week’s receipts with your reasons, in your own words, which the digest page shows and no share holds (from the Sprint 4 close: “The override reason is required and visible in the digest”). Deleted once its week started before the retention cutoff, so it never outlives the receipts it copies (§7).

5.17 modelAnswers

Since schema version 11 (Sprint 5.4): one row per claim Attest asked the optional model about, keyed by the claim’s id (src/ledger/model-answers.ts). A claim is asked only while you have a model on (Chrome’s on-device model, or your own key), and only while its receipt is still checking with a partial match: the one case where the model’s score can change a grade (docs/grading.md §5.4). The row is written before the model is asked, so a claim is asked once, ever. A grading batch reads the scores while a model is on; turned off, they count no more. Deleted with its claim by the purge (§7). Ids, a hash, a provider, an instant and numbers only: never the facts the model was given, never its words, never your key.

Index field: none (inputsHash is indexed as stored).

6. What is hashed

Every hash is SHA-256 (docs/grading.md §10). Addresses and calendar names are hashed as their UTF-8 text; a vendor’s row or event id is hashed as its canonical JSON string (the id in quotes), so that two ids differing only in a lone surrogate stay distinct. A hash hides a value from someone reading the ledger; it does not stop someone who can guess the value from confirming it (§2).

Kept in clear, because a claim is matched against them: recipient addresses, each Calendar event’s first guest address, merchant names, amounts and currencies, subjects and titles (80 code points), and times.

7. Retention and purge

Dated history is kept for the window you choose in the options page’s Privacy section: 30, 90 or 180 days, and 90 (RETENTION_DAYS, src/config.ts) until you choose. The choice is saved in meta retentionDays (src/ledger/settings.ts); the purge reads it in its own transaction, so a window saved between two purges applies at the next one. Below, “90 days” stands for the window. A service-worker alarm runs the purge once a day (alarms.ts), and again one minute after the browser starts when Chrome dropped the alarm. The rule is in src/ledger/retention.ts and runs in one transaction: all of it or none. The purge never trusts a clock that jumped ahead (src/ledger/retention-clock.ts): it runs at the wall clock, but no later than the latest instant the ledger stored (clockHighWater, or clockFloorAt after a repair) or two days past the last purge’s instant (purgeTrustedAt), whichever is later, and logs ledger.purge_clock_ahead when the clock is further ahead. In daily use that is the wall clock; a clock a year ahead deletes nothing current; a ledger nobody stored into for weeks catches up one day faster than real time per daily purge.

• Observations go 90 days after occurredAt, unless a kept receipt still names them as evidence. An observation dated after the cutoff (next month’s event of an old calendar claim) stays as long as the receipt that explains it.
• Claims and receipts go together: a claim made more than 90 days ago takes its receipt with it, and a receipt last graded more than 90 days ago takes its claim, unless current evidence keeps them (above). Evidence goes with its receipt, never before it.
• Requests go 90 days after they were sent, once no kept claim names them.
• Coverage intervals are cut at the cutoff: nothing before it is kept. Latest pings go once their last sync is older than the cutoff.
• Calendar snapshots go when they were read before the cutoff. A range not looked at since is compared with nothing next time, so its events come back as first sightings, never as changes.
• Clock repair spans (meta clockRepair.*) go once they ended before the cutoff.
• Alerts (§5.15) go with their receipts.
• Model answers (§5.17) go with their claims.
• Weekly digests (§5.16) go once their week started before the cutoff: up to a week before the receipts they copy, never after (security review SEC-7). They are deleted by their key, unread, so a digest that no longer reads goes too.
• Kept: grants, adapterHealth and the rest of meta are not dated history.
• While the ledger is encrypted and locked (§12) the purge waits, and runs again as soon as you unlock it, whatever the hour (src/background/catch-up.ts), so history never outlives the window because the purge kept finding it locked.
• Turning away detection off deletes every time away at once, and the idleOpen key with them. Receipts already made keep their reasons: an UNASKED receipt that counted a time away keeps the reason unasked.idle, and its replay inputs the signal, until the receipt itself goes.

Delete all data (the options page’s Danger zone, from Sprint 4.5; asked twice: a question, then a box you tick before Delete everything) deletes every storage bucket the ledger was in, and with each the folder of Chrome’s files that held it (§12, Chrome’s own copies), and clears chrome.storage.local and chrome.storage.session at once, and takes down every notification Attest shows (src/background/settings.ts): every table, the install id, the settings and the flags (Check Gmail for me is off again). No copy is kept anywhere: measured since the Sprint 6 close, none of 5,000 deleted sends was left in the profile’s files at once, or after the browser closed. chrome.storage.local then names the new ledger’s bucket, ledger-1 again. One choice is kept, never data: a page reader you turned off stays off, so a wipe never makes Attest read more (security review SEC-6); the confirmation says so. Attest keeps running, and pages you open afterwards are read into a new, empty ledger. Removing the extension removes its IndexedDB database and chrome.storage.local with it; Attest keeps nothing anywhere else.

Uninstalling Attest removes everything it keeps: Chrome deletes the extension’s storage buckets (the ledger’s; measured, its folder gone within a second), chrome.storage.local and chrome.storage.session, its alarms and its registered content scripts with it, and takes down its notifications. Outside the browser there is only what an option you turned on sent (§1): the usage numbers’ daily counts on Attest’s server, under an install id that then exists nowhere else (§11), and what your own model key’s company keeps under its own terms (§10).

8. The export

exportLedger (src/ledger/export.ts) is your copy of your data. pnpm attest replay reads it as it is: since Sprint 3.13 it carries each receipt’s inputs and policy (receiptInputs, policies, §5.12, §5.13), and since schema version 7 each batch’s coverage once (batchCoverages, §5.14). The options page’s Export section builds it itself, from paged reads of the ledger (never a whole table at once, src/ledger/export-file.ts), and saves it as one JSON file, attest-ledger-<date>.json, with the bytes exportLedger gives, through your browser’s own download: nothing is sent anywhere, and no downloads permission is needed. It also saves your receipts as one CSV file, attest-receipts-<date>.csv (src/ledger/export-csv.ts): one line per receipt, newest first, with its grade, state and reasons and the action it is about (type, time, counterparty, amount), but no override reason and no subject hint; a cell a spreadsheet could read as a formula is written after an apostrophe. Extension pages can also ask the service worker for the JSON with the bus query ledger.export, which the tests use.

{
  "format": "attest-ledger",
  "schemaVersion": 11,
  "exportedAt": "2026-10-09T09:30:00.000-04:00",
  "tables": {
    "requests": [],
    "claims": [],
    "observations": [],
    "grants": [],
    "receipts": [],
    "adapterHealth": [],
    "coverage": [],
    "meta": [],
    "coverageIntervals": [],
    "calendarSnapshots": [],
    "activity": [],
    "alerts": [],
    "digests": [],
    "modelAnswers": []
  },
  "receiptInputs": {},
  "batchCoverages": {},
  "policies": {}
}

It holds every table of §5, with exactly the fields listed there: index fields are stripped, and a row that fails its schema is left out (logged by id). With encryption at rest on, it is written opened, and meta’s encryption state (every crypto. key, §12) is left out (since the Sprint 6 close; security review SEC-4): it means nothing outside your profile, and its salt, rounds and key check would let whoever holds the file test guesses of your passphrase. It is deterministic: one read transaction, each table in key order, each object’s keys in schema order. An export made before Sprint 2.7 has no coverageIntervals or calendarSnapshots, one made before Sprint 4.6 or 4.7 no alerts or digests, and one made before Sprint 5.4 no modelAnswers; each still reads, with what it lacks empty. extension/tests/e2e/observers.spec.ts opens the Sent and Calendar fixtures with the built extension and checks that the export holds the labelled observations with allowlisted fields only.

Shares (Sprints 4.7, 4.8). A receipt (the side panel’s detail) and a weekly digest (the digest page) can each be shared, as text or as an image, which you see in full before you copy either: Attest copies it to your clipboard at your click and sends nothing anywhere. A share is made from the ledger’s derived facts only (src/ui/receipt-share.ts, src/ui/digest-share.ts). It names a counterparty by its domain only, and only from an address: a name gives nothing, even one written with a dot like “A.Kumar”, and a merchant gives its domain only when it is written as one (“Amazon.com”; src/ledger/domain.ts; security review SEC-1). It keeps amounts (one with no currency, behind a bare “$”, says so) and times, and shows a subject only as the hint the ledger keeps, with any address in it written as its domain. It never holds what you asked an agent, why you marked a receipt, or an address. A hint is the subject’s first 80 characters as written, so it can hold a name the subject held: you see it in the preview before you copy. Text that came from a page is escaped, so it can never become a link. The image draws exactly the same lines on a canvas in the page (src/ui/share-png.ts), in its light or dark colours. Every golden scenario’s receipts are checked against these rules, and the mandatory no-leak test searches the digest’s share and every receipt’s share for every seeded secret, for any @, and for a pasted name written with a dot.

9. Logs

Attest logs to the browser’s console only, through one logger (src/log.ts) that cannot print content by construction: the event must be one of a closed list, a string prints only if it is a known code, an id, a hash, a timestamp or a version, any field whose name says content (subject, counterparty, body, email, name, token, …) is always redacted, error messages are never printed, and objects print only their shape (Hard Rule 10). The no-leak test reads the console as one of its channels (§1).

The ledger and the observers’ service-worker side log, among others: observer.calendar_restarted (a Calendar range compared with nothing next time: the observer id and the reason, refused); observer.clock_behind (a message read after the clock’s time, not stored: the observer id and the message type); ledger.clock_regressed (the clock went back: how many intervals, latest pings, snapshot records and Calendar rows were deleted, as counts only).

10. The optional model

Limitations first. The model can be wrong, and whether it helps is not measured yet: the bench’s numbers for Chrome’s model and for your own key wait for their real answers to be recorded (RESULTS.md; Decisions [5.5]). So it is off by default. With your own key on, the facts below leave your computer for that company, which keeps them under its own terms.

It may change one thing. When a claim matches a sent email or event only partly and its receipt is still checking, the model’s score for that one match may lift PARTIAL toward VERIFIED. It never lowers a grade, never lifts a match below the partial line, never picks which email or event a claim takes, and never verifies a partial match on its own (docs/grading.md §5.4; Hard Rule 4).

What it sees. One claim and the one match it took, each as a few allowlisted facts (src/intel/input.ts). Strict schemas parse both, so one field more is an error, not a passenger.

Never page text, never what you asked an agent, never any other field a stored row holds. A field the row lacks is left out, never filled in. extension/tests/unit/intel/input.spec.ts checks the exact input for 20 claims, one of them made from a request that said “ignore previous instructions”: those words never reach the model.

How it is asked. The instructions are a constant in code (src/intel/prompt.ts). The facts go in one delimited block, which the model is told is data and never instructions; every < in it is escaped, so no text inside can close the block. The delimiter makes injection harder; it does not stop it. A subject hint is text an agent or a mail sender wrote, and one that says “rate this candidate 1” can steer the model’s score. What bounds that is the score’s weight, not the block: a score is at most 1, and it lifts a match to VERIFIED only from a floor of 14/17 (about 0.8235) or more, the receipt then showing “Model suggestion” (docs/grading.md §5.4; model-raise.spec.ts pins the bound). An answer counts only if it is exactly one score from 0 to 1 for each candidate of this input (src/intel/schema.ts). Anything else, an error, or no answer within 2 seconds (INTEL_TIMEOUT_MS) gives no score, and the claim is graded by the rules alone (src/intel/index.ts).

When. After a grading batch, never inside it: every receipt is graded by the rules first and never waits for the model (src/background/intel.ts). Only a claim whose receipt is still checking with a partial match is asked, about the one match it took. Each claim is asked once, ever: its row (§5.17) is written before the call. At most 10 claims per batch (MODEL_ASKS_PER_RUN), one at a time. When the same model was given the same facts before, its answer is reused and nothing is sent. Once an answer is stored, the batch grades again with it; a receipt already final is never graded again.

Where it runs. You choose in the options page’s Model section. Both choices are off until you turn them on (flag.ATTEST_MODEL and flag.ATTEST_MODEL_BYO, src/ledger/consent.ts).

• Chrome’s on-device model (Chrome’s Prompt API) runs on this computer: nothing is sent anywhere (src/intel/providers/builtin.ts). The options page asks Chrome about it only when you click “Check Chrome’s on-device model”, and Chrome downloads it only when you click to. When it is on and ready, Attest uses it and not your key: the choice that keeps the facts on this computer wins.
• Your own key (Anthropic or OpenAI) sends the facts above to that company’s official endpoint, api.anthropic.com or api.openai.com and nothing else, with your key in the request’s header (src/intel/providers/byo.ts). Before you turn it on, the options page says what is sent, to which host, that the company keeps it under its own terms, and that each check is billed to your key. The key is kept in chrome.storage.local, closed to content scripts, so no script on a Gmail or Calendar page can read it. It is never logged, never in the ledger, so never in an export, and it is deleted when you click Forget my key or Delete all data (src/background/byo.ts). While it is on, allowedHosts adds exactly that company’s host (§1).

What is kept. One row per claim asked: ids, a hash of the input, the provider, when, and the scores (§5.17). Never the facts given, the model’s words or your key. A model turned off makes its stored scores count no more; the rows go with their claims (§7).

Tests. extension/tests/e2e/intel.spec.ts runs it on the built extension against a stand-in for Anthropic: a paraphrased email claim goes from PARTIAL to VERIFIED, a not-found claim is never sent, and the only host contacted is Anthropic’s. extension/tests/property/monotonicity-batch.property.spec.ts grades random batches through the real grading path with every model score 0 and then 1: no grade changes but PARTIAL to VERIFIED.

11. Anonymous usage numbers

Limitations first. The install id joins your days: the server can tell that two days came from one install, though not whose, until you reset it (below). The server sees your network address when a payload arrives, as any server does. It uses the address only to limit how many payloads one client sends, as a salted hash kept in memory, and never stores or logs it (telemetry-api/README.md); Railway, which hosts it, keeps its own log of each request (the address, the browser’s full user agent, the path, the status, the timings) for 7 days on the Trial and Hobby plans and 30 on Pro, which Attest’s maker does not use (read from the service’s log fields and Railway’s documentation on 2026-10-13). Counts still say something: a day of many NOT FOUND receipts for one agent says that agent’s claims did not check out that day. And the install ids are random ones each copy of Attest makes, which the server cannot verify, so the floors below make made-up installs slow to add, not impossible.

Off unless you turn it on. In the options page’s Privacy section, Anonymous usage numbers: “Turn on usage numbers”. “Turn off usage numbers” stops it at once, and the next alarm sends nothing (flag ATTEST_TELEMETRY, src/ledger/consent.ts).

Where it goes. One host, TELEMETRY_HOST (src/config-network.ts), at one endpoint, POST /v1/aggregate, posted from the service worker (src/telemetry/send.ts). The host is attest-production-5149.up.railway.app, the API deployed on Railway on 2026-10-13 (Decisions [7.0]). Before that it was telemetry.attest.invalid, a name that never resolves (RFC 6761); pnpm build:release refuses a store build with such a host, or with a privacy policy that does not name the real one (Decisions [5.7]). While the numbers are on, allowedHosts adds exactly that host (§1).

How often. An alarm, attest.telemetry, looks every hour and sends the last whole day on your computer’s clock, yesterday, once. meta telemetrySentDay records the day when the server took it (§5.6), and a send that failed is tried again at the next alarm. While encryption at rest is on and Attest is locked, the day waits, and goes at the first unlock after it is due (src/background/catch-up.ts): the hour the server stores is then that unlock’s. A day is sent again only when the extension did not see the server take it (the answer lost, or the browser closed between the two); the server keeps one document per install and day, so it is stored once. A missed day is never sent later: only yesterday is ever sent. “Send a test payload now” sends that day at once and says in one line what happened; it never sends a day twice either.

What is published. Since Sprint 7, the server answers one public read, GET /v1/stats (telemetry-api/app/stats.py), about one closed calendar month: the latest whose reports are all in, since from the fourth day of the next month no report about it is taken (telemetry-api/app/days.py). Its answer never changes, so no two answers can be subtracted to find one install’s day. An install counts only when its reports about the month arrived on at least 3 days. Then, summed over the installs that count: how many there are, and for each agent how many of them used it, its receipts, and how many of those were VERIFIED, NOT_FOUND and UNASKED, each also as a rate of the receipts. Never an install id, any one install’s day, or anything else a report holds. While fewer than 50 installs count it publishes nothing (204), and an agent used by fewer than 50 of them is published as nothing (null). A client may keep the answer an hour. The monthly reliability report is filled from it alone (launch/reliability-report-v0.md).

What it holds. Counts, yes-or-no values, fixed words, the install id, two versions and the date. src/telemetry/aggregate.ts builds it from the ledger and src/telemetry/schema.ts parses it; the schema allows no other string, and the server’s is held equal to it (telemetry-api/tests/payload.schema.json). The options page shows exactly what the next send holds. Below is the payload the real builder made of an invented day: extension/tests/tools/telemetry-example.ts seeded a ledger with that day and wrote the block, and extension/tests/unit/docs/telemetry-example.spec.ts fails when the block is not exactly what the builder makes today. Its install id is invented, and Chrome’s version comes from an example user agent.

{
  "installId": "0b7e1c52-9d4a-4f3e-8a61-5c2d7e9f1a3b",
  "extVersion": "0.1.2",
  "chromeMajor": 141,
  "dayBucket": "2026-10-09",
  "adaptersEnabled": {
    "muse": false,
    "chatgpt": false,
    "dots": false,
    "claude": false
  },
  "observersEnabled": {
    "gmail": true,
    "gcal": true
  },
  "counts": {
    "muse": {
      "VERIFIED": 3,
      "PARTIAL": 1,
      "NOT_FOUND": 2,
      "UNASKED": 0,
      "OVER_SCOPE": 0,
      "UNVERIFIABLE": 0
    },
    "chatgpt": {
      "VERIFIED": 0,
      "PARTIAL": 0,
      "NOT_FOUND": 0,
      "UNASKED": 0,
      "OVER_SCOPE": 0,
      "UNVERIFIABLE": 0
    },
    "dots": {
      "VERIFIED": 0,
      "PARTIAL": 0,
      "NOT_FOUND": 0,
      "UNASKED": 0,
      "OVER_SCOPE": 0,
      "UNVERIFIABLE": 0
    },
    "claude": {
      "VERIFIED": 1,
      "PARTIAL": 0,
      "NOT_FOUND": 0,
      "UNASKED": 0,
      "OVER_SCOPE": 0,
      "UNVERIFIABLE": 1
    }
  },
  "adapterHealth": {
    "gcal.event": "OK",
    "gmail.receipt": "DEGRADED",
    "gmail.sent": "OK"
  },
  "coverageHours": {
    "gmail": 7,
    "gcal": 9
  }
}

Resetting the install id. In the options page’s Danger zone, “Reset install id”, then “Reset id”. Attest makes a new random id, and payloads after it cannot be linked to those before (src/ledger/install-id.ts resetInstallId). Delete all data removes it too (§7).

On the server. It stores each payload as it came, with the hour it arrived, one per install and day, and nothing else: never the address, never a header. The hour, not the minute: an install’s sends arrive at the same minute past the hour each day, which could otherwise join an install id to the one a reset replaced. It takes a payload only about a day from two days before its own UTC date to the day after, at most 24 payloads per install id and 240 per client a day, and payloads for at most 4 install ids per client a day (so one client alone can make at most 45 installs count in a month, fewer than the floor); the rest are refused and never stored. Each payload is deleted 90 days after it arrived, by the database itself, after the two months in which its month is read. Reports already sent stay there until then: deleting your data in Attest, or resetting the install id, does not reach them (telemetry-api/README.md).

Tests. extension/tests/e2e/telemetry.spec.ts runs it on the built extension: off, nothing is sent; on, one payload a day, exactly the one the options page showed, to its one host. The secret-seed test (§1) searches what telemetry sends, and what the page showed, for every seeded secret.

12. Encryption at rest

Off unless you turn it on, in the options page’s Encryption (since Sprint 6.5; extension/src/crypto/, src/background/crypto.ts). Most people will not want it: Attest then asks for your passphrase once each time Chrome or Attest starts.

What is sealed. Every row of the nine tables that hold content: requests, claims, observations, grants, receipts, calendarSnapshots, receiptInputs, digests and modelAnswers (SEALED_TABLES in src/config-crypto.ts). A row keeps in the clear only the fields IndexedDB keys and indexes it by, and its index fields; every other field is sealed together, as one value:

So a recipient’s address, a merchant, an amount, a subject, an event’s title and guests, what an agent claimed and what you asked it, your grants, your marks and their reasons, every receipt’s reasons and signals, a digest’s lines and the model’s answers are sealed. The other tables hold ids, hashes, codes, counts, instants and your settings, and stay as they are.

Your own model key. If you saved one (§10), it is sealed too while encryption is on, in chrome.storage.local under the same key, with additional data naming it, so no other sealed value opens as it (since the Sprint 6 close; security review SEC-2; src/background/byo.ts). It is sealed when you turn encryption on, sealed again under a new passphrase, and opened for good when you turn encryption off; it opens only in the service worker, with the key it holds. While Attest is locked, the key does not open, and no question goes to the model, as grading waits anyway; a key cannot be saved while it is locked, since it could not be sealed. Its company, attest.byoVendor, stays readable: it says only which company’s key you saved.

How. The key is PBKDF2 with SHA-256, 600,000 rounds, over your passphrase in Unicode NFC (one passphrase typed on two keyboards is one key) and a random 16-byte salt made when you turn encryption on and again at each new passphrase: a 256-bit key (src/crypto/kdf.ts). Each sealed value is AES-256-GCM under that key, with a fresh 96-bit nonce from the browser’s random source, and the table and the row’s key as additional data, so a value moved to another row or table does not open (src/crypto/seal.ts). meta keeps the key’s id, the salt, the rounds and a key check (§5.6): a fixed text sealed with the key, which tells a right passphrase from a wrong one before any row is read. Your passphrase is at least 12 characters; it is never stored, never logged, and goes only to Attest’s own service worker, which derives the key. Chrome hands a page’s message to Attest’s other open pages too, and each of them drops it without keeping or logging it; no website or script on a page ever receives it (Sprint 6 close; security review SEC-9).

Where the key lives. In the service worker’s memory, and, for Attest’s own pages, in chrome.storage.session (attest.ledgerKeys, §5), which Chrome keeps in memory and empties when the browser closes or Attest reloads, and which no content script can read. Never on disk, never in the ledger, never in an export. Each start of the service worker clears that copy before it answers any command, trying twice, so the ledger is locked again after a browser restart, an update of Attest, or a restart of the service worker, until you type the passphrase in the popup or any page that asks for it. A page that cannot read its keys again drops the ones it had: it is locked, never left reading with keys from before a lock (since the Sprint 6 close; security review SEC-5). While the ledger is unlocked, the service worker keeps itself running (a cheap extension API call every 20 seconds, src/background/keep-awake.ts), so Chrome’s stop of an idle worker does not lock it every half minute; between a stop Chrome makes anyway and the next start, the pages’ copy stays in Chrome’s session memory, and that next start clears it.

Locked. Every read and write of the nine tables fails whole, a count or a key alone included: nothing is read in part (src/crypto/middleware.ts). The popup and the other pages say the records are locked and ask for the passphrase; a wrong one is refused and reads nothing. The service worker stores nothing a Gmail or Calendar tab sends, its coverage least of all, so a claim of that time stays UNVERIFIABLE, never NOT_FOUND (Hard Rule 5); a pasted import is refused; and grading, the purge, the digest and the usage numbers wait for the unlock (src/background/locked.ts). Lock now, in the options page, locks every page at once, and clears the pages’ copy of the keys even when the service worker itself holds none.

A new passphrase, or turning it off. Both need the passphrase in use. A new one gets a new key and salt, and a job seals every row again under it, a page of rows per transaction, resuming where it stopped after any restart; until it ends, the key before is kept in meta sealed under the new one, so the new passphrase alone resumes it. Turning it off opens every row for good, with the same job, and then deletes every crypto. key. A step that fails for another reason than the lock (a row that does not open, or storage that refuses a write) stops the job, and the options page says so and why, never as progress; the grace alarm tries it again while it is unlocked, up to three failed steps in a row, and Try again resumes it at once (since the Sprint 6 close; tech review TECH-2). Lock now works while a job runs.

Chrome’s own copies. Chrome keeps IndexedDB in files where a changed row is written anew, and the version it replaces stays until Chrome compacts those files; Chrome’s undo log for each change keeps one more copy. Measured on 2026-10-12 (red-team strategy 13, docs/attacks-that-work.md), a ledger of 5,000 sends sealed in place kept 1,200 to 2,400 of them readable in its files, after the browser closed as well. Deleting a database has Chrome compact its rows away, but on a thread of its own after the deletion has answered, and a write that lands at that moment leaves them in a file Chrome still uses: measured on 2026-10-13 with four browsers at once, a ledger rebuilt by deleting and remaking its database kept rows under the key a new passphrase replaced in 5 runs of 12. So since the Sprint 6 close the ledger lives in a storage bucket of its own, ledger- and a number (src/ledger/place.ts; Chrome 122 and later), whose IndexedDB Chrome keeps in a folder of its own and deletes whole with the bucket. Once a job has sealed every row (encryption turned on, or a new passphrase), Attest rebuilds the ledger (src/ledger/rebuild.ts): every row is copied as stored into the ledger of the next bucket, which so holds each row once, and counted; the next bucket is named the one in use (attest.ledgerBucket, §5); and the bucket before is deleted, its folder and every older copy of a row with it. Measured after: 0 of the 5,000 sends in the files at once, ten seconds later and after the browser closed; and with four and six browsers at once, no row under the replaced key in 36 runs of 36, read the moment the change ended. Sealing and rebuilding those 5,000 took 2.9 seconds. While it runs, Attest’s pages wait to read (attest.ledgerRebuild), and the options page says so. A stop of the service worker before the next bucket is named leaves the ledger as it was and the rebuild due; a stop after leaves the bucket before, which the worker’s next start deletes. Delete all data deletes every ledger bucket the same way (§7).

What it costs. Measured on 2026-10-13 over the 30-day ledger (5,000 claims, 50,000 observations; extension/tests/e2e/perf-ledger.spec.ts, pnpm bench, perfMonthSealed* in RESULTS.md): sealing every row took 19.5 seconds, and the rebuild into the next bucket 11.2 more, while the options page said each. Sealed values do not compress as plain rows do, so the sealed ledger took 58.8 MB, against 40.2 MB unsealed; with the bucket before deleted whole, that was all it took right after the rebuild too. The popup’s first paint while unlocked was 64 ms, under its 100 ms gate, and the JSON export took 6.3 seconds, against 3.2.

What it protects. A copy of your Chrome profile (the files on disk, a backup, another account on the computer that can read them): without the passphrase, the sealed fields cannot be read, and a wrong passphrase reads nothing. Tested on the built extension: extension/tests/e2e/encryption.spec.ts (sealed at rest with the sends’ addresses and subjects absent from IndexedDB read directly, read back whole, a restart of the service worker and a browser restart locking it, a wrong passphrase refused) and extension/tests/e2e/redteam-encryption.spec.ts (red-team strategy 13: a copied profile, near-miss passphrases, a change mid-session, and the profile’s files read without Chrome, as a forensic tool reads them: every send found there before encryption is on, none once it is, before the copy is opened or after, and no row under the old key after a new passphrase; docs/attacks-that-work.md).

What it does not protect.

• Anyone using this browser while Attest is unlocked. The pages show your records as they did before. Lock now, or closing Chrome, locks them.
• The fields kept in the clear. Someone with a copy of the profile can count your receipts of each grade, and see when each claim, send and event was, which agent made it and what kind of action it was; not to whom, what, or how much.
• The tables without content (§5): adapter health, coverage and its windows, meta, activity, policies, batch coverages and alerts.
• An export. It is written opened, as the unlocked ledger reads (§8): treat an export file like the unlocked ledger. It leaves out the encryption state, so it carries no way to test a guess of your passphrase.
• A guessed passphrase. 600,000 rounds slow each guess, but a short or common passphrase can still be guessed from a copy. Use a long one.
• A forgotten passphrase. Nobody can open the records, Attest included. Delete all data is the only way back.
• A damaged record of the key. If meta’s record of the key (its id, salt, rounds or check, or mid-change the key before) is damaged, by a disk error or an edited profile, no passphrase opens the records: Attest says the record is damaged, never that the passphrase is wrong, and logs which field, never its value (since the Sprint 6 close; security review SEC-6). Delete all data is the only way back here too. A row sealed under a key the unlocked ledger does not hold reads as unreadable, never as locked, so the unlock prompt does not come back for it.
• A copy taken while the job or the rebuild runs. Until the rebuild ends, Chrome’s files can still hold rows as they were before; the options page says when it has.
• The disk itself. Chrome deletes a deleted bucket’s folder, and the files a compaction replaces; it does not overwrite them. A tool that recovers deleted files from the disk, rather than copying the profile, may find older copies of rows there. Full-disk encryption (FileVault, BitLocker) covers that; Attest cannot.
• Another storage engine. The measures above are of the LevelDB store Chrome uses for IndexedDB today. The end-to-end tests read the files again on every run, so a change in Chrome’s storage would show there first.
• Memory, and a compromised browser or computer. While Attest is unlocked, the key is in the browser’s memory, as any unlocked secret is. Malware on the computer, or another extension or program able to read Chrome’s memory or your typing, can read the records while they are unlocked, or take the passphrase as you type it. Encryption at rest guards a copy of the profile, not a running browser that is no longer yours.