Revue
DocumentationPrivacy and security

Privacy and security

What Revue keeps on your computer, where your tokens are, and everything it talks to over the network.

Revue is a desktop app that talks straight to the services you sign in to. There's no Revue cloud between you and GitHub, Bitbucket or Forgejo: your code and comments go from your computer to those services, and nowhere else. A Revue account is optional: it keeps your sign-ins, end-to-end encrypted, so they follow you to your other computers. Without one, nothing goes to Revue's account server at all.

In short#

  • No usage tracking. Revue doesn't record what you click, which pull requests you open, or how you use it.
  • Error reports, in official releases: when Revue crashes or runs into a bug, it sends a short report so it can be fixed. You can turn this off. See Crash and error reports.
  • Tokens stay on this computer, in a file only you can read, or in your system's credential store if you turn that on. With a Revue account, the sign-ins you keep in it also go to Revue's account server, encrypted on your computer first: see Your Revue account.
  • Images you paste into comments are uploaded to Revue's image server and are public to anyone with the link. See Images in comments.

Your tokens#

When you sign in, Revue keeps the token (or OAuth refresh token) on this computer only. It never goes in the config folder, which you might sync between computers. Another computer that syncs that folder gets your accounts, but not their tokens, and asks you to sign in again there. (A Revue account is the way to have your sign-ins on every computer: below.)

You choose where the tokens are kept in Settings → Storage → Where tokens are kept:

SwitchOff (default)On
macOS: Keep tokens in the macOS KeychainA file readable only by youYour login keychain
Windows: Keep tokens encrypted for your Windows userA file readable only by youA file encrypted for your Windows user (DPAPI)
Linux: Keep tokens in the Secret Service (GNOME Keyring, KWallet…)A file readable only by youThe Secret Service (GNOME Keyring, KWallet, KeePassXC…)

Turning the switch off moves the tokens back to the file and deletes the store's entry. The switch is for this computer only.

Where tokens are stored, exactly
WherePath or name
The file (Linux)~/.local/share/revue/sign-ins.json, mode 600
The file (macOS)~/Library/Application Support/revue/sign-ins.json, mode 600
The file (Windows)%LOCALAPPDATA%\revue\sign-ins.json (local, never the roaming profile)
macOS KeychainA generic password: service revue, account sign-ins
Windows, encrypted%LOCALAPPDATA%\revue\sign-ins.bin, encrypted with DPAPI for your user
Linux Secret ServiceAn item labelled Revue sign-ins (revue), attributes application=revue, kind=sign-ins, through secret-tool
  • All tokens are one entry, so the keychain asks at most once, not once per account.
  • They're read once, on first use, and kept in memory after that.
  • If the store is on but can't be used (no desktop session, secret-tool missing, a locked or refused keychain), tokens are kept in the file meanwhile. The next start that can reach the store moves them there.
  • Revue never writes over a store entry it couldn't read: it may be fine once the store is unlocked.
  • Development builds use revue-dev in place of revue everywhere, so they never share tokens with the installed app.
Tokens from your environment (GitHub)
  • By default Revue only uses the GitHub accounts you signed in to inside Revue.
  • With Also sign in with the gh CLI or GITHUB_TOKEN / GH_TOKEN on (Settings → Accounts), it also reads GITHUB_TOKEN, GH_TOKEN, or runs gh auth token. Those tokens are used, not stored.
  • REVUE_GITHUB_TOKEN, when set, is used alone.

See Command line and environment variables.

Your Revue account#

A Revue account is off until you create one or sign in to one. Until then Revue asks nothing of the account server, not even whether it hosts accounts, unless you open Settings → Accounts.

With one:

  • End-to-end encrypted. Revue encrypts each sign-in on your computer, with a key only your computers have, before it goes to the server. The server keeps only ciphertext, padded so its size doesn't tell what it is, and named by a keyed hash: it can't see your tokens, which services you use, or who you are on them.
  • Your password never leaves your computer. Revue derives two keys from it (Argon2id): one proves your password to the server, the other unlocks your sign-ins and never leaves your computer. The server can't get one from the other.
  • What the server does see: your email, the language of its mails, your computers' names, systems and Revue versions, when and from which network they connect (an address cut to its /24 after a week), and how many encrypted items you keep and their sizes. See the server's /privacy page (on Revue's: https://revue.cleangame.dev/privacy).
  • On each computer, the account's keys and its decrypted copy of your sign-ins are kept where Revue keeps tokens (Settings → Storage → Where tokens are kept): never in the config folder.
  • A recovery key is shown once when you create the account. Without it (or a computer still signed in), a forgotten password means starting over: the server can't unlock your sign-ins for you.
  • Two-step sign-in (an authenticator app) keeps someone with your password alone from downloading your encrypted sign-ins. It can't protect against a breach of the server itself: what's there is ciphertext either way.
  • Rollbacks are refused. Each computer remembers the newest version it saw of every item; a server handing back an older one is ignored.
  • Account servers must use https:// (plain http:// only on your own computer).
  • Export and deletion: Settings → Accounts → Revue account → Security… saves an encrypted backup or a readable export, and deletes the account.
  • In a browser: the account's web page can list, add and remove your sign-ins too (Revue account in a browser). The browser opens them with your password and encrypts a pasted token before sending it, so the server still sees only ciphertext. A server may also offer Sign in with the service there: that sign-in goes through the server, which sees the token for that moment to hand it to your browser (never stored or logged). Pasting a token, or signing in in the app, keeps it end-to-end.
  • In the web version (/app of the account server, The web version at /app): bringing your sign-ins hands their tokens to the web version's own server, as if pasted, and an OAuth sign-in's refresh token with it, so the web version can renew it. It renews in turn with your computers (a short lock on the item, as they do) and saves the new tokens back to your account, encrypted in the browser, so none of you is signed out. To do that across reloads, the browser keeps your account's key split in two: the key encrypted under a random key of its own in the browser's storage, and that random key in the web version's server, encrypted with the session like its tokens. Neither half opens anything alone: the server has its half but never the encrypted key, the browser's storage the encrypted key but not the half to open it. Together they do: someone who has both this browser's storage and its session cookie (this browser, unlocked, or malware on it) could open your sign-ins while the session lasts, as they could use the sign-ins the web version already holds. Sign out of Revue account in the web version drops both halves; Sign out everywhere, or the session ending, drops the server's. The browser's session at the account server stays in use while the web version is open with sign-ins to renew (its 8-hour limit still holds, or 30 days kept signed in), and for that session it may also list your encrypted items, lease one and write it over its version (what saving a renewal takes), but not add or remove one without your password.

What Revue keeps on disk#

Revue has three folders. All of them belong to you alone, and you can delete them when Revue isn't running.

FolderWhat's in it
Config (the one to back up or sync)Settings, your accounts (without their tokens), drafts and viewed files for each pull request, imported themes, what the app remembers (open tabs, filters)
Data (this computer only)Settings for this computer only, the token file, downloaded language servers, the running Revue's link port
Cache (can be thrown away)Saved API responses, source checkouts for the Code tab, avatars and images, Slack people and emoji, app icons
Where these folders are, per system
FolderLinuxmacOSWindows
Config~/.config/revue~/.config/revueC:\Users\<you>\.config\revue
Data~/.local/share/revue~/Library/Application Support/revue%APPDATA%\revue (and %LOCALAPPDATA%\revue for the token file)
Cache~/.cache/revue~/Library/Caches/revue%LOCALAPPDATA%\revue
  • XDG_CONFIG_HOME moves the config folder on every system. On Linux, XDG_DATA_HOME and XDG_CACHE_HOME move the other two.
  • Inside config: settings.json, state.json, tokens/ (accounts, without secrets), prs/ (one file per pull request: drafts, reply drafts, viewed files), color-themes/, slack-choices.json.
  • Inside data: settings.local.json, sign-ins.json, language-servers/, instance-port.
  • Inside cache: http/ (API responses), sources/ (checkouts), img/ (avatars and images, kept 7 days), opened/ (files opened in your editor from a checkout), app-icons/, slack/ (Slack workspaces' people and emoji, refreshed daily, deleted when you sign out of Slack), settings-cache.json.

More about syncing the config folder: Files, sync and settings for one computer.

What Revue talks to#

Revue only connects to these. Each one only when you use what needs it.

WhatWhenWhat's sent
GitHub (api.github.com, github.com)You're signed in to GitHubAPI requests with your token
Bitbucket Cloud (api.bitbucket.org, bitbucket.org)You're signed in to BitbucketAPI requests with your token
Forgejo, Codeberg, Gitea (each server you add)You're signed in to that serverAPI requests with your token
Jira (your Atlassian site, auth.atlassian.com, api.atlassian.com)You connected JiraTicket requests with your token
Slack (slack.com)You connected SlackReading the threads you picked, and posting only when you ask it to (for example Notify in Slack)
Revue's server (revue.cleangame.dev)You paste, drop or pick an image in a commentThe image
Revue's account server (revue.cleangame.dev, or the one you chose)You open Settings → Accounts (whether it hosts accounts), and, with a Revue account, at start, when you switch to Revue and every 5 minutesYour email and the keys derived from your password when signing in; your sign-ins, encrypted on your computer
Revue's releases (forgejo.cleangame.dev)At start and every hourA request for the latest version number. See Updates.
Language-server downloads (github.com releases, nodejs.org, the npm registry)Only when you turn language servers on and one set to Bundled is neededOrdinary downloads. See Language servers.
Error reports (glitchtip.cleangame.dev)Official releases, when something breaksSee Crash and error reports
Images and avatars in pull requestsWhen you look at themFetched from wherever they're hosted, as a browser would

Things Revue starts on your computer also connect on their own: git (clones, fetches and pushes, with your own git credentials), your editor, terminal and language servers.

Sign-in connections
  • GitHub sign-in uses the device flow: you type a code on github.com. Nothing comes back to your computer except through the API.
  • Bitbucket, Jira, Forgejo and Slack sign-ins open your browser. When you approve, the browser comes back to Revue on your own computer, at http://localhost:47392/callback or http://127.0.0.1:47392/callback. Revue listens there only while a sign-in is going on, and only on your computer's loopback address.
  • The code the browser brings back is swapped for tokens directly with the service.
  • OAuth sign-ins with Atlassian, Forgejo and Slack get a new token from time to time; each computer signs in on its own so they never use up each other's. Kept in a Revue account, one computer renews and the others take its new tokens through the account.

Images in comments#

When you paste a screenshot, drop an image file, or use the editor's Image button, Revue uploads the image and puts a Markdown image link in your comment. This works the same on every service, GitHub included.

  • Images go to Revue's server (revue.cleangame.dev in official releases), not to GitHub, Bitbucket or Forgejo.
  • Anyone who has the link can see the image. The link is the image's fingerprint (SHA-256), so it can't be guessed, but it isn't private either.
  • Uploaded images aren't deleted.
  • Only PNG, JPEG, GIF and WebP are accepted, up to 10 MB by default.

Want images to stay in-house? Run your own server and point Revue at it with REVUE_SERVER_URL and REVUE_IMAGES_TOKEN. See Self-hosting revue-server.

Advanced: uploads in detail
  • Upload is on only when Revue knows a server and an upload token (REVUE_SERVER_URL, REVUE_IMAGES_TOKEN, built into official releases). Without them, the Image button inserts ![image](https://) for you to fill in, and pasting an image does nothing special.
  • Copying from an app that puts text along with a picture (a word processor, say) pastes the text, not an image.
  • The server keeps one file per distinct image: uploading the same screenshot twice gives the same link.
  • The server checks the bytes, not the file name: anything else, SVG included, is refused.
  • The default server limits uploads to 120 per hour per address, and logs each upload with the address it came from.
  • Errors show as Couldn't upload the image: ….

Two features use Revue's server for links, so that people without Revue still get somewhere:

  • Copy Revue link gives a web link like https://revue.cleangame.dev/github.com/acme/web/pull/12.
  • Revue's links in Slack messages go through https://revue.cleangame.dev/link?url=….

The page opens the pull request in Revue for people who have it, and the web page otherwise. Whoever clicks it loads that page from the server, which sees the pull request's address. Revue itself sends nothing to the server for this. See Links and opening from anywhere.

Crash and error reports#

Official releases send a report when Revue crashes, or when it runs into a problem that looks like a bug. This is how bugs get found and fixed.

Reports are not sent for the everyday things you can see and act on yourself: being offline, an expired sign-in, a missing permission, a rate limit, a service that's down or busy.

To turn reports off, start Revue with REVUE_SENTRY_DSN set to an empty value:

REVUE_SENTRY_DSN= revue

On Windows, set REVUE_SENTRY_DSN to an empty value in your user environment variables. There's no switch in Settings for it.

What's in a report

Reports go to Revue's GlitchTip error tracker (the Sentry protocol) at glitchtip.cleangame.dev.

A report holds:

  • what failed and the error message (for API errors this can include the request's path, such as a repository name);
  • for a crash: the panic message and a stack trace of Revue's code;
  • the Revue version;
  • the operating system and its version, the processor architecture, the Rust version;
  • the computer's name (host name), which the reporting library adds by default.

It doesn't hold your tokens, your code, comment text, or your accounts. Revue doesn't set any user identity on reports.

The same problem is reported at most once an hour. On quit, Revue waits up to two seconds for reports still being sent.

Builds you make yourself don't report unless you set REVUE_SENTRY_DSN to an address. See Command line and environment variables.

So that revue LINK and revue:// links open in the Revue that's already running, Revue listens on a random port on 127.0.0.1, reachable only from your own computer. It writes that port to instance-port in its data folder.

  • Only pull request links are acted on: anything else shows Not a pull request link: ….
  • Opening a link only opens a tab. It never posts, approves or changes anything.
  • Editors' Revue Companion (VS Code, Zed) listen on 127.0.0.1 too, and answer Revue only with the random token they recorded with revue --companion, in a file in Revue's data folder readable only by you. Revue only asks them what they have open and to open a folder; nothing in their record is ever run (see Telling Revue an editor runs).
  • The revue:// handler is registered only when you click Register as handler in Settings → Apps. Unregister removes it.
What registering changes, per system
SystemWhat Register as handler does
LinuxWrites ~/.local/share/applications/revue-url-handler.desktop and makes it the default for x-scheme-handler/revue (xdg-mime)
WindowsAdds HKEY_CURRENT_USER\Software\Classes\revue (your user only, no administrator needed)
macOSNothing to do: Revue.app declares revue:// itself

Trying things without leaving a trace#

revue --immutable runs Revue on a throwaway copy of its settings and data, deleted when it quits. Tokens are copied into memory only. Changes you make on the services themselves (comments, reviews, merges) are still real. Full details: Command line and environment variables.

Removing everything#

To remove all trace of Revue from a computer:

  1. Sign out of each account in Settings → Accounts, if you also want the tokens revoked on the service's side (or revoke them on the service). With a Revue account, Sign out of it on its card (or delete it in its Security…).
  2. If you turned on the credential store, turn it off in Settings → Storage → Where tokens are kept. This deletes the store's entry.
  3. If you registered the link handler, click Unregister in Settings → Apps.
  4. Quit Revue.
  5. Delete the config, data and cache folders (see What Revue keeps on disk).