4DA Systems Pty Ltd (ACN 696 078 841) takes the security of 4DA and its users extremely seriously. This document describes our security policy, vulnerability disclosure process, and the security properties of the application.

Only the latest release in the 1.x series receives security updates. Users should always run the most recent version.

Do not open a public GitHub issue for security vulnerabilities.

Report privately through either channel:

• GitHub private vulnerability reporting: open the repository's Security tab and choose Report a vulnerability. This creates a private advisory that only you and the maintainers can see.
• Email: security@4da.ai

Include:

• A clear description of the vulnerability
• Steps to reproduce the issue
• Your assessment of the impact (e.g., data exfiltration, privilege escalation, code execution)
• Any proof-of-concept code or screenshots
• Your preferred attribution name (if you want credit)

We will keep you informed of our progress throughout the process.

4DA Systems will not pursue legal action against security researchers who:

• Make a good-faith effort to avoid privacy violations, data destruction, and service disruption
• Report vulnerabilities promptly and provide reasonable time for remediation before any public disclosure
• Do not exploit vulnerabilities beyond what is necessary to demonstrate the issue

With your permission, we will acknowledge your contribution in the release notes of the version that addresses the vulnerability. If you prefer to remain anonymous, we will respect that.

4DA is a local-first desktop application. By design, it minimizes attack surface by keeping data and computation on the user's machine.

• Memory safety. The Rust backend eliminates entire classes of vulnerabilities: buffer overflows, use-after-free, data races.
• Credential storage. API keys and the licence key are stored in the OS credential store (Windows Credential Manager, macOS Keychain, Linux Secret Service). A key is removed from settings.json (and its settings.json.bak) only after a read through a fresh credential-store handle returns the identical value; on first start after upgrading, keys found in plaintext are migrated all-or-nothing. If the credential store is unavailable (headless CI, locked keychain, no keyring service on some Linux setups), the key stays in settings.json, which is restricted to the current user (owner-only ACL on Windows, mode 0600 elsewhere), and Settings → AI Provider says the key is kept in settings.json instead of claiming secure storage. An empty value or a failed read never deletes or overwrites a stored key. With FOURDA_DATA_DIR set, profile secrets use a separate per-profile credential-store service.
• Path canonicalization. All file system operations canonicalize paths to prevent symlink and directory traversal attacks.
• SSRF prevention. Outbound HTTP requests on content-fetch and updater paths validate the URL and block private/internal IP ranges via validate_url_safe_for_request. Webhook registration validation is being hardened in v1.1; user-supplied webhook URLs should be treated as trusted until then.

• Content Security Policy. Strict CSP enforcement: no inline scripts, no iframes, no eval().
• HTML sanitization. All rendered HTML is sanitized with DOMPurify before insertion into the DOM.

• Signed updates. Application updates are signed with Ed25519 (minisign). The updater verifies signatures before applying any update.
• Code signing. Windows binaries are not yet Authenticode-signed (planned); verify them with the published SHA-256 checksums and minisign signatures (docs/VERIFY-DOWNLOADS.md). macOS binaries are signed and notarized by Apple.

• cargo-deny. Enforced in CI to audit Rust dependencies for known vulnerabilities, duplicate crates, and license compliance.
• SBOM. A CycloneDX Software Bill of Materials is published with every release, accompanied by a cosign attestation.

• The 4DA desktop application (all platforms)
• The update and auto-update mechanism
• The bundled MCP server mcp-memory-server (@4da/mcp-server has its own policy: https://github.com/4DA-Systems/4da-mcp-server/security/policy)

• Third-party dependencies. If you find a vulnerability in an upstream dependency, please report it to the upstream maintainer. We will update promptly once a fix is available.
• Social engineering of 4DA Systems employees or contributors.
• Denial of service against infrastructure (4da.ai, update servers).
• Attacks requiring physical access to an unlocked machine where 4DA is running.

These are architectural properties, not claims of invulnerability.

• BYOK (Bring Your Own Key). API keys are stored in the OS credential store (see "Credential storage" above for the owner-only settings.json fallback used when the store is unavailable) and are only transmitted to the providers the user has explicitly configured. 4DA Systems never receives or stores user API keys.
• Local-first, direct-to-provider. 4DA has no server-side database, no user accounts, and no 4DA-operated analytics, tracking, or backend storage. Your indexed content, scores, and decisions stay in a SQLite database on your machine. The only outbound traffic is:
  • Source adapters fetching public content (Hacker News, GitHub, Reddit, arxiv, CVE/OSV feeds, etc. — all documented in NETWORK.md).
  • BYOK LLM providers you have explicitly configured (Anthropic, OpenAI, or localhost Ollama).
  • License validation (Keygen) if you have activated a paid license.
  • Update checks against the signed updater endpoint on GitHub Releases.
  • No crash reporting or telemetry. 4DA sends no crash reports to any server. If you hit a bug, Settings → Privacy → Export diagnostics builds a scrubbed, local report (usernames and secrets redacted) that you review and choose whether to attach to a bug report. Nothing is transmitted automatically.
• No 4DA-operated cloud. 4DA Systems does not run a data collection backend. Nothing you index, search, or read is ever sent to 4DA servers — because there are no 4DA servers for it to go to.
• On-device activity log. 4DA records UI activity (tab opens, result clicks, feedback) in a local SQLite table to power relevance learning and the compound-intelligence system. This data stays on your machine and is never transmitted. Activity logging is gated by a Privacy → Activity Tracking setting and is off by default, opt-in only.
• Database encryption. The default public build uses bundled SQLite without at-rest encryption. The SQLCipher scaffolding exists for self-compiled builds. Opt-in at-rest encryption for the default installer is on the v1.1 roadmap.
• No accounts. There is no user database, authentication system, or session infrastructure to breach.

For the authoritative list of every outbound connection with source-code references, see NETWORK.md and docs/NETWORK-TRANSPARENCY.md.

For security matters: security@4da.ai

For general inquiries: https://4da.ai

4DA is licensed under FSL-1.1-Apache-2.0. See LICENSE for details.