What is defended, and what is not.

The model

RVLTION defends one thing: keeping credentials out of a file that would otherwise accumulate them. Everything else follows from being a local application with no network surface.

It does not defend against someone who already has access to your user account. If an attacker can read your home directory they can read your clipboard history, and they could also read your browser profile, your SSH keys, and your documents.

Secret filtering

Three layers, applied before persistence, cheapest first.

• Operating system signal. On Windows, the registered clipboard formats that mark content as excluded from history. Password managers set these. Honouring the signal beats guessing from content.
• Source application. A denylist of credential managers matched on whatever identifier the platform provides, so it works on an executable name, a bundle identifier, or a process name.
• Content heuristics. Published token shapes first, then a general high entropy check.

Layer three is heuristic by nature. A password that looks like an ordinary word will pass it. Layers one and two carry the real weight, and layer one does not work on macOS or Linux yet, so the heuristics carry more of the load there.

Attack surface

• No listener. RVLTION opens no port and binds no socket, including for single instance enforcement. There is nothing to connect to.
• No inbound anything. No URL scheme handler, no IPC endpoint reachable from outside the process, no plugin system.
• No remote code. The interface is bundled at build time. Nothing is fetched or evaluated at runtime, and the content security policy would block it if it were.
• No elevation. It installs and runs as your own user and asks for no administrator rights.

Single instance

Only one RVLTION may own the database and the clipboard listener at a time. Two would produce duplicate captures and interleaved writes.

This is enforced with operating system primitives rather than a socket: a named mutex on Windows, and an atomically created lock file elsewhere holding the owner process id. The pid is what makes it recoverable. A machine that lost power mid session would otherwise leave a lock nobody owns, and an application that refuses to start until you find and delete a file is a worse failure than the duplicate it was preventing.

The Windows path is the one that has actually run. The lock file path has never been executed, since no macOS or Linux binary has been built, so the rule it depends on is tested directly instead: a lock naming a process that no longer exists is treated as abandoned, and an unreadable one is too.

Dependencies

Four runtime dependencies in the interface: React, React DOM, Zustand, and the Tauri API bindings. The backend pulls the Tauri runtime, SQLite compiled in rather than linked from the system, and the platform clipboard bindings.

The dependency tree is audited each phase for anything network capable. The current count is zero: no HTTP client, no TLS stack, no socket library, no telemetry crate. The full list is on the licenses page.

That audit is of the Windows tree, which is the only one that has been resolved. A Linux build will differ in one honest respect: every graphical application on Linux talks to its display server over a local socket, and clipboard access on both X11 and Wayland goes through that same connection. It carries no network traffic and reaches nothing beyond your own machine, but it is a socket, and the sentence above should not be read as covering a Linux build until that tree has been resolved on Linux.

Known limitations

The database is not encrypted. This is the most important limitation on the page. RVLTION filters what goes into the file; it does not protect the file.

• Content based secret detection is heuristic and will miss things that do not look like credentials.
• On macOS and Linux the first defence layer does not work yet. Those platforms do have a convention: macOS password managers mark a copy as concealed, and KDE applications set a password manager hint. The clipboard library RVLTION uses on those platforms reads text and images rather than arbitrary clipboard types, so it cannot see either marker. Reading them needs native code written on a machine that can compile and test it.
• Clipboard history is inherently sensitive. If you copy something you would not want recorded, the safest action is to clear history rather than to trust a filter.
• Builds are unsigned, so their authenticity cannot be verified by your operating system.

Signing status

No build of RVLTION is signed. There is no code signing certificate for Windows and no Apple Developer identity for macOS.

Windows SmartScreen will warn on a build it has not seen before, and Smart App Control may refuse it outright. macOS Gatekeeper would refuse an unsigned application for the same reason. These warnings are correct: an unsigned binary genuinely has no verified origin.

Do not disable Smart App Control or Gatekeeper to work around this. Both are protecting you from a real category of problem, and Smart App Control in particular cannot be re enabled without reinstalling Windows. The correct fix is a certificate, which does not exist yet.