Security

Whitney Solutions · Whitney Pages

Your documents never reach us

Whitney Pages opens, edits, and exports PDF files entirely on your device — in your browser or in the desktop application. There is no upload step, no server-side rendering, and the application works with the network switched off. Nothing about the contents, names, or structure of a document you open is sent anywhere.

What the sign-in service holds, and why

A separate, small service handles who may sign in. It holds only what that requires:

• Your email address and which organization it belongs to.
• Sessions: when you signed in, when a session was last used, and when and why it ended, so an administrator can see who has access and end a lost device's session.
• An audit trail of administrative actions — who invited, removed, or changed the role of whom, and when.
• Rate-limit counters, keyed by email address and by network address, that stop anyone guessing sign-in codes.

Signing in

There is no password. An administrator invites you by email, and you sign in with a one-time six-digit code or a single-use link, both sent to your address. A code is stored only as a salted hash, expires after ten minutes, and is limited to three requests per address every fifteen minutes; five wrong attempts locks the address out for fifteen minutes. These limits are enforced in the database, so they hold even when more than one copy of the service is running.

Notices, and seeing your own sessions

When your account signs in from a network it hasn't used recently, you're sent an email saying so. Only a scrambled fingerprint of each network is kept, never the address itself. Your account page lists every browser and desktop app signed in to your account, and lets you sign any of them out. A change to your email address is only made after a code sent to the new address is entered, and your old address is always told.

Administrators use passkeys

The people at Whitney Solutions who administer organizations sign in to the admin console with a code sent to their email and a passkey, a credential held by their own device. A passkey can't be phished or replayed on another site. Losing access to a mailbox is not enough to get into the console.

Sessions, and what ending one means

A session is a row in our database, not a credential the application can renew on its own. Signing out, being removed from an organization, having your role changed, or an administrator choosing "Sign out everywhere" all end sessions the same way: by ending the row. The next request that needs one fails.

An installed copy that is online rechecks its access when it starts, when its window regains focus, and hourly, so revocation reaches it within the hour. A copy that cannot reach the service — offline, on a flight — keeps working for up to 14 days from its last successful check, and then stops. That allowance is what makes an offline-first application usable; it is also the honest limit of how fast a revocation can reach a machine that has no network to tell it.

Separating organizations in the database

The database uses PostgreSQL row-level security, enforced on every table that holds tenant data, so a request scoped to one organization cannot read another's rows even if a query has no predicate saying so. The role the application connects as owns no tables and cannot bypass row-level security; a distinct, more limited role handles the few operations — creating an account, looking up which organization issued a sign-in code — that necessarily span organizations, and it is granted only the specific statements those operations need, with no ability to delete the audit trail. No process connects as a superuser at request time; a superuser is used only to apply schema migrations, as a deliberate, separate step from serving traffic.

Encryption

All traffic to the application and the sign-in service is encrypted with TLS. The database is hosted by Neon on Amazon Web Services, which encrypts data at rest.

Desktop updates

The desktop application checks for updates and installs them only after asking; installer packages are signed, and the operating system verifies that signature before running one.

The PDF libraries, and what they are not allowed to do

Whitney Pages reads and writes PDF files with pdf.js and pdf-lib. Both are vendored into the application itself rather than fetched from a third party at run time, and a build fails if either file's contents do not match a pinned hash — including pdf.js's worker, which cannot carry the same integrity check a script tag can, and which runs untrusted document bytes through it. pdf.js is also run with its JavaScript-evaluation fallback explicitly disabled, so a crafted font program in a PDF cannot be compiled and executed as code.

A strict content security policy

The application is served under a content security policy that names every host it is allowed to reach, forbids inline scripts other than the one bundle the build ships and hashes, and blocks the page from being framed by another site. The policy is checked automatically at build time against the hosts the code actually contacts, so the two cannot drift apart unnoticed.

Knowing when something breaks

Errors in the sign-in service are reported to an error-monitoring service so they can be fixed quickly. Those reports carry no cookies, request bodies, email addresses, sign-in codes or tokens; they are removed before anything leaves our servers.

Backups

The database is backed up continuously and can be restored to any point in time within its retention window. Restoring is tested on a schedule, not assumed: a restore drill creates a fresh copy of the database as it stood at a specific past moment and confirms the data in it matches expectations, rather than only confirming that a restore command exits without error.

Reporting a vulnerability

If you believe you have found a security issue in Whitney Pages or its sign-in service, please tell your organization's administrator, who can reach Whitney Solutions directly.