Privacy Policy

Optional companion service

This copy has no companion service configured. Cloud sync, D&D Beyond character lookups, posting to Discord and sending updates to readers all need one, so none of them can happen here. Your bastions are saved in this browser and go nowhere on their own; the sections describing those features are omitted because they would describe nothing this copy does. The one thing that does leave this page without a companion service is a stat reference: tapping a creature or spell glyph fetches that entry from the public Open5e API, which sends the name you tapped and nothing about your bastion. It is only ever on a tap, and it can be switched off in Settings.

Optional D&D Beyond character import

If you use the D&D Beyond import tool, the app looks up the public character JSON for the character ID you provide, via this instance's relay — the same relay described under cloud sync below. Nothing it holds is written to disk, and nothing it holds survives a restart. No account credentials are involved, and nothing you import is kept server-side — it's copied into your local bastion save just like anything else you build in the app.

Optional cloud sync (Google Drive or Dropbox)

Cloud sync is opt-in and off by default — it never turns itself on. If you connect it from Settings, the app keeps a single backup of your bastion library in a private, app-scoped folder inside your own cloud storage, so you can pick the same library up on another device. The five sections below describe in full how the app accesses, uses, shares, stores, protects, retains, and deletes Google user data. The same handling applies to Dropbox except where noted.

1. Data accessed

When you connect Google Drive, the app requests exactly one OAuth scope: https://www.googleapis.com/auth/drive.appdata. That scope grants access only to a hidden, application-specific folder (appDataFolder) that no other app and no other user can see. It does not grant access to any other file in your Drive — not your documents, photos, or anything you did not create through this app. Within that folder the app accesses:

• One file it created itself, bastion-library.bastion, containing the bastion saves, app settings, homebrew catalog entries, shelved snapshots other people shared with you, the campaign labels you filed them under, and any private notes you wrote about them — everything you authored or kept in the app. It contains nothing else from your device.
• A small sync marker on that same file's appProperties, used only to notice when another of your own devices has pushed a newer copy.
• OAuth access and refresh tokens issued by Google so the app can reach that one folder.

The app requests no profile, name, email address, contacts, or any other Google account information, and no other Google API or Drive scope. If Google returns an identity token alongside the access token, the relay strips it — it never reaches the app.

Connecting Dropbox instead of Google Drive is the same arrangement with a different provider: the app holds the files.content.read, files.content.write, and files.metadata.read scopes against a dedicated App folder under Apps in your Dropbox, reaching only that folder and nothing else you keep there. Dropbox has no appProperties equivalent, so the sync marker rides a small companion file, sync-channel.json, in that same folder.

2. Data usage

The data above is used for one purpose only: synchronising your own bastion library between your own devices. The app reads the file to bring a device up to date, merges it against what is on that device (newest-wins, prompting you when both sides genuinely diverged), and writes the merged result back. That is the entire processing lifecycle, and it runs in your browser.

Your Google user data is never used for advertising, marketing, profiling, analytics, credit or lending assessment, resale, or to train, fine-tune, or improve any AI or machine-learning model. No human — including the operator of this instance — reads it.

3. Data sharing

Your Google user data is not sold, rented, traded, or shared with any third party, and not transferred to any advertising, data-broker, or analytics platform. It travels between your browser and Google's own API and nowhere else. The only other component involved is this instance's relay service, which brokers the sign-in step alone: it exchanges your authorization code for tokens and hands them straight back to your browser. Your synced file travels between your browser and Google only — the relay never receives, stores, or forwards it, and never holds your Google user data beyond the moment of that exchange. The app has no product backend and keeps no server-side copy of your Google user data.

The limited exception is disclosure required by law, which the operator would comply with only if legally compelled.

Bastion Builder's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

4. Data storage & protection

• Where it lives: the synced file is stored in your Google Drive account, under your own Google credentials and Google's own security and encryption protections. The operator of this instance has no access to it.
• Tokens: your access and refresh tokens are held in your browser's localStorage, on your device only. They are transmitted nowhere except back to Google (via the relay) to refresh the session.
• In transit: all traffic to Google's APIs and to the relay is encrypted over HTTPS/TLS. If this instance runs behind a CDN or tunnel such as Cloudflare (a common setup for the Docker image), that infrastructure is a processor for encrypted traffic passing through it in transit — it does not receive a separate copy of your Drive/Dropbox data.
• Nothing the relay holds is written to disk, and nothing it holds survives a restart: no database, no session store. Only access_token, refresh_token, expires_in, scope, and token_type are passed back; every other field is dropped. Access logging is off by default; if an operator turns it on for troubleshooting, it never includes your IP address, and authorization codes and tokens (carried in request bodies) never reach a log line regardless.
• Least privilege: because the app holds only the drive.appdata scope, even a compromised token reaches this app's own hidden folder and nothing else in your Drive.

5. Data retention & deletion

The app retains exactly one synced file, overwritten in place on each sync — it keeps no version history, no archives, and no secondary copies. That file is retained for as long as you choose to keep it: since it lives in your own Drive, its retention is entirely under your control, and the operator can neither extend nor shorten it. Tokens are retained on your device until you disconnect or clear your browser data.

You can remove your data at any time, without contacting anyone:

• Disconnect in Settings — discards the stored tokens on that device and revokes the app's access at Google. This deliberately leaves your backup file in Drive, so disconnecting never destroys data you may still want.
• Delete the synced file in Google Drive: Settings → Manage apps → Bastion Builder → Options → Delete hidden app data. This permanently removes the app's folder and everything in it.
• Revoke access yourself from your Google account's third-party access page, or your Dropbox connected-apps page.
• Delete the local copy by removing the bastion in the app, or clearing this site's browser storage.

Because the operator holds no copy of your Google user data, there is nothing further for them to erase on your behalf. If you would still like confirmation or assistance with a deletion request, contact this instance's operator using the details under Who operates this instance; requests are answered within 30 days.

Optional updates to readers

If you share a bastion by link, you can opt in to letting whoever holds that link ask you for fresh copies. This is off by default and never turns itself on: a link made without it carries no return address at all, and nothing can be sent to anyone until you tick their name and press send.

When you do send one, a copy of that bastion — the same read-only snapshot a share link carries — passes through this instance's relay on its way to that one reader. This is the one case where the relay handles the contents of a bastion. What it does with it:

• It holds it in memory only, addressed to that single reader, and deletes it the moment they collect it. Nothing is written to disk and nothing survives a restart of the service — there is no database and no archive.
• It is deleted after 14 days whether collected or not.
• It is never served to anyone else. Each message has exactly one named recipient, and the key that collects it is created on that reader's own device and never travels in a share link.
• Asking sends your name and nothing else. A reader who asks for updates sends only the name they type — no account, no address, nothing about their own bastions. It is unverified, and shown that way.
• Access logging is off by default, and even when an operator turns it on, the keys that identify these messages are removed from the log line.

You can stop at any time by removing a reader from your list; they are not told, and nothing further is sent to them. A reader can likewise stop receiving updates from their own shelf. Neither of you can withdraw the copies already delivered — those live on the other person's device, exactly as a shared link does.