I've been building R2 Desk Pro, a desktop client for Cloudflare R2,
and the most interesting engineering problem was the security
architecture: how do you build a desktop app where credentials
genuinely cannot leak through the frontend?
The threat model: a Tauri app runs a Rust backend and a webview
frontend. If credentials touch the webview, they're accessible to
JavaScript — same exposure as a browser extension. That's not
acceptable for long-lived R2 keys with read/write/delete access
to production storage.
Here's what I ended up with:
*Vault layer*
Argon2id KDF derives a 256-bit key from the user's passphrase.
The vault state is checked at the start of every Tauri command
handler. If the vault is locked, the command returns an error
before any R2 operation executes. The frontend never holds the
key — it only knows whether the vault is open or closed.
*Credential storage*
R2 access keys are stored in the OS keychain via the keyring
crate (Windows Credential Manager, macOS Keychain, libsecret on
Linux). Nothing sensitive touches the filesystem or app settings.
*Backend-only R2 requests*
All S3 operations run in Rust using the AWS SDK. The frontend
calls Tauri commands like `list_objects` or `upload_file` — it
never constructs signed requests or holds credentials long enough
to use them. The signing happens entirely in the backend.
*Session lock*
On macOS: NSWorkspaceSessionDidResignActiveNotification triggers
vault auto-lock when the session goes inactive.
On Windows: WM_WTSSESSION_CHANGE handles the same.
On Linux: XScreenSaver / logind signals.
The cross-platform session lock was the most painful part — each
OS has a completely different event model and Tauri doesn't
abstract this for you.
*The tradeoff*
This architecture means the frontend is essentially a dumb UI.
Any operation that needs R2 access goes through a Tauri command.
That's more round-trips than a purely frontend approach but the
security boundary is clean and auditable.
Happy to discuss the implementation details — particularly the
Argon2id parameterisation choices and the keyring abstraction
across the three platforms.
pio_greeff•2h ago
The threat model: a Tauri app runs a Rust backend and a webview frontend. If credentials touch the webview, they're accessible to JavaScript — same exposure as a browser extension. That's not acceptable for long-lived R2 keys with read/write/delete access to production storage.
Here's what I ended up with:
*Vault layer* Argon2id KDF derives a 256-bit key from the user's passphrase. The vault state is checked at the start of every Tauri command handler. If the vault is locked, the command returns an error before any R2 operation executes. The frontend never holds the key — it only knows whether the vault is open or closed.
*Credential storage* R2 access keys are stored in the OS keychain via the keyring crate (Windows Credential Manager, macOS Keychain, libsecret on Linux). Nothing sensitive touches the filesystem or app settings.
*Backend-only R2 requests* All S3 operations run in Rust using the AWS SDK. The frontend calls Tauri commands like `list_objects` or `upload_file` — it never constructs signed requests or holds credentials long enough to use them. The signing happens entirely in the backend.
*Session lock* On macOS: NSWorkspaceSessionDidResignActiveNotification triggers vault auto-lock when the session goes inactive. On Windows: WM_WTSSESSION_CHANGE handles the same. On Linux: XScreenSaver / logind signals.
The cross-platform session lock was the most painful part — each OS has a completely different event model and Tauri doesn't abstract this for you.
*The tradeoff* This architecture means the frontend is essentially a dumb UI. Any operation that needs R2 access goes through a Tauri command. That's more round-trips than a purely frontend approach but the security boundary is clean and auditable.
Happy to discuss the implementation details — particularly the Argon2id parameterisation choices and the keyring abstraction across the three platforms.
https://r2desk.greeff.dev