Design stage: there is no released app yet. This site separates what exists in the repository from what is planned. See status
Simca
EspañolRequest access

Launcher

Updates and privacy

The launcher has no account of its own. When you open it and it is connected, it asks once whether a signed update exists. It never polls, and it never installs anything on its own.

Status

Built (repo) The logic exists as a tested library in the repository (a mock fetcher stands in for the network). Designed The launcher screens, the HTTP request itself and the installer are not built. Not decided Whether the default for the opening request is on, and the hosting of the manifest, are for the owner to confirm. This replaces the earlier rule that nothing is contacted until you press Check (ADR-0003).

What happens when you open the launcher

  • If it is connected to the internet, it makes one plain request for a signed update manifest: a static file.
  • The request carries no account data, no identifier and no usage information. There are no timers, background services or scheduled tasks, and nothing is requested again until you press Check.
  • If a newer version exists you see a visible notice you can dismiss. This happens even if the app is set to Offline login, because Offline only means the app itself signs into no cloud.
  • Applying the update is always your action: a verified signed package, a disk-space check, a backup, a staged download, and a real rollback to the previous version if something fails.
  • You can also install an update from a signed file (USB, messenger, nearby device) with no network at all, under the same checks.

What the request does reveal

Like any web request, it shows your network address and the time to whoever serves the manifest. The repository lists these mitigations: a plain static file on any host, no cookies or identifiers, a manifest source you can change (including a community mirror or none), and the app never makes this request itself. A setting to switch off even the opening request is implemented in the library as recommended; its default is still for the owner to confirm.

Safety rules in the library

  • The manifest is signed, expires and carries a sequence number so an old file cannot be replayed.
  • A missing or empty checksum is an error, never skipped.
  • A list of blocked versions can stop a bad release, and a rollback never selects a blocked version.
  • The running program is never overwritten: the new one is written as a successor file and switched atomically.
  • Any update error fails open: the installed version keeps working.

Not built or not decided

  • The launcher user interface, installers and the HTTP fetcher.
  • Hosting for manifests and downloads, and the launcher shell technology (open decisions D7 and D33).
  • Resume and delta download in the launcher, version pinning, channel switching and safe mode.

Launcher overview · The opening request · Secure updates · Open decisions