Skip to content
finwave Docs

For IT Teams

In this guide you will learn:

  • What filesystem and network access the desktop client has
  • How the Tauri permission model restricts the application
  • What the audit log records and how to export it
  • How to deploy the client across your organization using silent install, MDM, or group policy
  • How credentials and data are secured

Security posture at a glance

Section titled “Security posture at a glance”

The finwave Desktop client is a background service that scans filesystems, reads image metadata, and uploads data to a cloud API. IT teams should understand exactly what it does and does not do.

CapabilityStatus
Read user-selected directoriesAllowed (user must explicitly grant each directory)
Write to user data directoriesDenied (enforced by Tauri sandbox)
Write to ~/.finwave/Allowed (app data only)
Network requestsHTTPS to a single configurable API domain only
Telemetry or analyticsNone. No data sent to third parties.
Clipboard, screen capture, email, contactsDenied (not requested)
Audit logAlways on. Cannot be disabled.

Tauri permission model

Section titled “Tauri permission model”

The client is built on Tauri v2, which uses a capability-based permission system enforced at the OS level. The declared permissions are:

  • fs:read-files — read files in user-selected directories only
  • fs:read-dirs — list directory contents
  • fs:write-app-data — write to ~/.finwave/ only
  • dialog:open — folder picker dialogs
  • notification:default — desktop notifications
  • shell:open — open URLs in the default browser
  • http:default — HTTPS requests to the configured finwave API domain only
  • os:default — OS info (platform, version)
  • autostart:default — launch on startup (user-configurable)

Notably absent: no fs:write-files for user directories, no clipboard, no shell:execute, no global-shortcut, no window:allow-screen-capture. The fs scope restriction is OS-level sandboxing, not application-level — it cannot be bypassed by application code.

Network transparency

Section titled “Network transparency”

The client communicates exclusively with a single configurable API domain (default: api.finwave.io). All traffic is standard HTTPS (TLS 1.2+). There are no third-party analytics services, no crash reporting endpoints, no external telemetry of any kind.

Certificate pinning is enabled. The client pins the finwave API’s TLS certificate chain to prevent man-in-the-middle attacks. If the certificate does not match, the connection is refused and an error is logged.

Verify the client’s network behavior by inspecting the API domain in the app’s configuration, monitoring network traffic with your own tools, or reviewing network entries in the audit log.

Activity audit log

Section titled “Activity audit log”

The client maintains a comprehensive, append-only audit log at ~/.finwave/logs/. Logs are rotated daily. Every significant action is recorded, including:

CategoryWhat is logged
FilesystemDirectory added/removed from watch, scan started/completed with file counts, batched file reads during metadata extraction
NetworkAPI request method, endpoint, response code, bytes transferred, upload start/completion, connection state changes
AuthLogin, logout, token refresh, token expiry, re-authentication prompts
ConfigManifest created/updated/approved, sync config changes, directory watch state changes
SyncEncounter staged/confirmed/skipped/uploaded, duplicate detection, sync cycle summaries
ErrorAny error with full context (failed uploads, scan errors, permission denied, timeouts)

The log never contains file contents, pixel data, authentication tokens, or spreadsheet values.

Credential storage

Section titled “Credential storage”

API tokens are stored exclusively in OS-native credential storage:

  • macOS: Keychain Services
  • Windows: Windows Credential Manager (DPAPI)
  • Linux: Secret Service API (GNOME Keyring / KDE Wallet)

Credentials are never written to config files, log files, or local databases. They exist only in the OS keychain and in-memory during the session.

Code-signed builds

Section titled “Code-signed builds”

All release builds are signed:

  • macOS: Apple Developer ID, notarized with Apple
  • Windows: Authenticode EV code signing certificate
  • Linux: GPG-signed packages

SHA-256 checksums are published with each release for integrity verification. Auto-updates verify the new binary’s signature before applying; if verification fails, the update is rejected and an error is logged.

Silent installation

Section titled “Silent installation”

For deploying across multiple machines, the client supports silent installation with pre-configured settings:

Terminal window
finwave-desktop install \
  --api-url=https://api.finwave.io \
  --data-dir=/opt/finwave-data \
  --autostart=true \
  --silent

MDM and group policy support

Section titled “MDM and group policy support”

You can lock settings via managed configuration so users cannot change them:

  • Windows: Group Policy registry keys
  • macOS: Managed preferences (MDM profile)
  • Linux: System-wide config file at /etc/finwave/policy.json

Locked settings appear grayed out in the app UI with a note: “This setting is managed by your organization.”

Lockable settings include: API endpoint URL, autostart behavior, auto-confirm (force off to require manual review), data directory location, bandwidth limits, and allowed directory roots.

Centralized logging

Section titled “Centralized logging”

The audit log can optionally be forwarded to a syslog endpoint or written to a network share, allowing you to aggregate logs from all desktop clients into your SIEM or monitoring platform.

Section titled “Related”