Companion App

No. The Companion App verifies your presence automatically in the background when your laptop connects to the office network.

Yes - your admin needs to enable occupancy tracking and add the office's public IP address in Skedda settings. If you expect automatic check-ins, they also need to enable that in the relevant check-in rules.

Automatic check-in is an optional feature that must be enabled by your admin. Check with your IT team or Skedda administrator to confirm whether automatic check-in rules have been set up for your workplace.

No. The Companion App runs passively in the background and persists across restarts. There's no need to keep a browser tab open.

Open the app from your menu bar (Mac) or system tray (Windows) and sign in again. Once signed in, it will resume tracking automatically.

The Companion App is designed for company-managed work laptops. Using it on a personal device is possible but not recommended. Check with your IT team or admin.
​

Yes. Occupancy tracking uses your organisation's public IP addresses, and Skedda protects all data with encryption in transit, encryption at rest, and standard access controls. Occupancy data is not shared with third parties. By default, it is retained for 1 month and then deleted — your admin can adjust this period in Skedda's Data Retention settings.

Below you can find a comprehensive security-related overview of the Skedda Companion app.

The Skedda Companion is a lightweight, native system-tray application that helps improve on-site detection accuracy for Skedda customers.

A user installs Companion on their device. While it runs, the app periodically "pings" or "calls" the Skedda backend from the user's current network. The backend looks at the public IP the incoming request is associated with, compares it to the venue's configured on-site network ranges, and — if the IP matches — marks the user as "seen-on-site" for that day. If the venue has auto-check-in enabled, this implies the user is automatically checked into their bookings for that day.

The app has no main window; its entire UI is a system-tray icon and menu.

Companion is a tray-only native Rust app built on Tauri v2. It has no webview — no HTML, no JavaScript, no remote content is ever loaded or rendered inside the app. This removes the entire "insecure webview" threat class (no CSP bypass, no XSS, no devtools exposure). The only code that ever runs inside the app is the build-time application core plus the Tauri plugins it bundles; no code is loaded from the network or from user-supplied input at runtime.

Ships as: macOS .app/.dmg, Windows NSIS (per-user install, no admin rights required), Linux bundles.

The token stored by Companion is not a general Skedda login or web-session token. It is issued specifically for Skedda's native client applications (the Companion desktop app and Skedda's mobile apps that assist on-site detection by pinging the backend on the user's behalf — the backend itself performs the on-site detection). Its only valid use is the on-site-detection flow in §1.2.

The token does not grant the ability to sign into the Skedda app, read or change bookings directly, view other users' data, or call any other Skedda API.

Companion has no code path to collect: hostname, device name, MAC address, Wi-Fi SSID/BSSID or nearby networks, file contents, installed apps, browser history, keystrokes, screen/clipboard contents, microphone/camera/GPS, or any third-party analytics/telemetry/crash-reporting SDK.

Server-side processing (retention, purpose, sub-processors, deletion rights) is governed by the Skedda Privacy Policy and DPA, not by this document.

The scopes above are what the app asks for. An admin can independently enforce that boundary at the OS or network layer, so that any future version, supply-chain incident, or runtime compromise would still fail if the app strayed outside this behaviour.

All outbound traffic is HTTPS via reqwest with the OS trust store (SChannel on Windows, Secure Transport on macOS, system roots on Linux). https:// is hardcoded; there is no plaintext HTTP in production. Connect timeout 10 s, request timeout 30 s. No URL, header, or payload field is sourced from untrusted input at runtime.

The skedda-companion:// handler parses the URL with a standard library, then requires scheme skedda-companion, host auth, a single non-empty token query parameter of at most 4 096 bytes; duplicate or extra token keys are rejected. A tauri-plugin-single-instance guard ensures a second-launch forwards its deep link into the running process (no race).

App updates are delivered via the Tauri updater plugin. The update manifest is fetched from app.<your-authority> and the signed artifact is downloaded from cdn.<your-authority>. Every downloaded artifact is verified against a minisign public key embedded in the app binary before install; unsigned or mismatched payloads are rejected. Checks occur 30 s after launch and every 24 h; Windows installs run in passive NSIS mode without UAC (per-user scope).

The token is held in the OS keychain via the keyring crate: macOS Keychain, Windows Credential Manager, Linux Secret Service. Service com.skedda.companion, account user-token. Writes are verified via read-back; memory cache covers transient keychain failures. Sign-out clears both memory and keychain.

Structured logs via tauri-plugin-log to the OS log directory (stdout only in debug builds). 5 MB rotation, 3 files retained. Tokens are always masked to ***<last-3-chars>; request and response bodies are never logged verbatim.

Production dependencies are a small, audited set: Tauri v2 (core + updater/deep-link/autostart/notification/single-instance/log plugins), reqwest (HTTPS), keyring (OS credential store), tokio (minimal feature set), serde, url. No third-party JavaScript ships in the binary (the only Node dependency is @tauri-apps/cli for build scripts). The repo runs routine dependency audits to surface advisories in these crates.