Security assurance case

This document argues that Floe meets its security requirements for its intended environment: a local macOS launcher used by one person on their own Mac. It follows the structure of Thaw’s assurance case, but Floe’s risks are its own. The largest is that Floe runs third-party extensions without a sandbox.

Update it when a trust boundary or a major feature changes.

Security requirementsCopy Anchor Link

You can expect that:

1. Floe runs on your Mac, with no Floe account and no analytics. Its data stays on the Mac unless you turn on iCloud sync or use a feature that talks to a service you chose, such as an AI provider or a sign-in.
2. macOS asks before Floe gets a protected permission, such as Accessibility, Calendar or Contacts.
3. A link from another app can’t complete a sign-in or change Floe’s look unless it answers a request Floe made.
4. Passwords, sign-in tokens and AI keys are kept in the Keychain. Sign-in tokens belong to the installed extension that saved them, and an AI key belongs to the address it was saved for.
5. Updates come over HTTPS and are checked with Sparkle’s EdDSA signature. Releases are signed with a Developer ID and notarized. See Verifying releases.
6. You can report a security problem privately, and the maintainers aim to acknowledge it within 48 hours.

You can’t expect that:

1. An extension or script command is contained. It runs under your account and can reach your files and the network. Only run code you trust.
2. Floe protects you from someone who already controls your unlocked Mac session.
3. Older releases get security fixes. Only the latest stable release is supported.

Threat modelCopy Anchor Link

What needs protectingCopy Anchor Link

ScenariosCopy Anchor Link

Out of scope: physical access to an unlocked Mac, bugs in macOS, and compromise of Apple’s notarization service.

Trust boundariesCopy Anchor Link

  Other apps and scripts                     You
     │ floe:// links, notifications          │ the launcher, Settings, macOS prompts
     ▼                                       ▼
  ┌───────────────────── Floe (your account) ─────────────────────┐
  │  link routing and request checks  │  signed process messages  │
  └───┬───────────────────┬───────────────────┬───────────────┬───┘
      │ stdin/stdout      │ Sparkle           │ AppleScript   │ Keychain
      ▼                   ▼                   ▼               ▼
  Bun, one per command   HTTPS and EdDSA    Other apps      macOS
  (no sandbox)

Secure design principlesCopy Anchor Link

These are the Saltzer and Schroeder principles.

Common weaknesses counteredCopy Anchor Link

CodeQL, SonarCloud and SwiftLint run in CI. A nightly fuzz run with AddressSanitizer covers IncomingLink.

Residual risksCopy Anchor Link

1. Extensions aren’t contained. This is Floe’s largest risk, and it comes with running unmodified Raycast extensions. An extension can read your files, reach the network, start programs and run scripts in your browser’s tabs through the BrowserExtension API. Floe records what it sees, which a hostile extension could avoid. Floe also doesn’t disclaim responsibility for its child processes, so macOS may treat an extension’s request as Floe’s and apply the permissions you gave Floe.
2. Store extensions aren’t pinned. They come from the current raycast/extensions tree, so Floe relies on GitHub’s HTTPS and that repository’s review. Floe doesn’t check a signature on them.
3. Bun runs with loosened code signing. To run JavaScript, the bundled Bun has JIT and unsigned executable memory allowed, library validation off and DYLD variables allowed. Anyone who can already run code as you could use those entitlements, and Bun is signed with Floe’s team.
4. Sign-in goes through raycast.com for now. Raycast’s page sends the browser back to Floe. It’s temporary and may stop working, as What Floe does not do yet says.
5. Local apps can see process notifications. Signatures stop forgery, but another app can read a message and its payload, such as the settings page on screen. The one link sent this way is Thaw’s appearance answer; a sign-in’s return is never forwarded.
6. Fuzzing covers one parser. It covers link routing and the sign-in state. It doesn’t cover Thaw’s appearance answers, settings import or extension manifests, which rely on Swift’s memory safety and unit tests.
7. Coverage has limits. Statement coverage is measured on SonarCloud against the exclusions in sonar-project.properties. Branch coverage isn’t measured.

EvidenceCopy Anchor Link

RevisionCopy Anchor Link