Tilo

Trust and safety

Use this page to decide what belongs on a machine or in a shared workspace. Neither “open source” nor “encrypted” answers that question on its own.

The public alpha is not published yet. The sections below describe the security boundaries Tilo is designed to provide. Before relying on one, confirm that its control is present in the build and that the release notes mark it as available.

Know which installation you are trusting

The complete Tilo operating system controls the whole chain: signed boot image, encrypted disk, read-only verified system, image updates and repair mode.

Installing Tilo as a desktop session adds the workspace, app sandbox, collaboration and interface to an existing Linux distribution. That distribution still controls its kernel, boot chain, encryption, administrators and system updates. The session cannot honestly make guarantees about layers it does not own.

A virtual machine isolates Tilo from the host by default, but a folder, clipboard, USB device or network service you deliberately share crosses that boundary. The VM interface lists every such share.

Check what an application can reach

An app does not start with the run of your home directory, camera, microphone or network. Picking a file gives it that file. Dragging an item gives it that item. A denied folder looks absent rather than becoming a mysterious object the app knows exists but cannot read.

Standing access—camera, microphone, location, screen capture, broad network access and background work—appears in Permissions. It names who or which app has access, what it can do, and whether the grant is once, until logout, or until revoked.

Adding an app keeps its verified package on disk. It grants nothing and runs no install script. Open can run an app without keeping it; closing that app discards its temporary workspace and grants.

Normal Linux applications run too. Tilo confines them and mediates files and devices, but cannot infer a meaningful action history from private app state. If you deliberately run a tool outside that confinement, the desktop shows the broader access before starting it.

Treat each workspace as a sharing boundary

Apps in one workspace do not acquire files, input, devices or collaborators from another merely because both run on the same computer. A workspace with colleagues and a Personal workspace containing a bank statement are different places.

People and agents receive named permissions. Incoming changes are checked before becoming part of the workspace, and History records the author’s identity. Transport is encrypted and authenticates the admitted devices.

That protects data in transit and limits future access. It cannot make somebody forget information already received, recall an exported file or prevent a photograph of the screen. Revocation stops later reads and accepted changes; the confirmation says which earlier copies remain outside its reach.

Stop remote input when something feels wrong

Viewing a shared window and typing into it are separate grants. Remote input is shown continuously while active, your physical keyboard and pointer take priority, and Super + Esc stops every remote input grant immediately.

After an emergency stop, People shows which connections remain and offers Disconnect and Remove access separately. Stopping input is never described as recalling data or ending a connection that is still open.

Keep control of your identity

There is no vendor account required for the desktop or peer-to-peer workspaces. A person-scoped collaboration identity authorises devices and signs workspace changes. A device certificate can be revoked from another device without replacing the identity.

The recovery copy handles losing every authorised device. Setup creates it before the identity is used for sharing and asks you to keep it away from the computer. It is not a routine login secret.

A TPM makes day-to-day unlock quieter; it is not the owner of the identity. A machine without one uses a longer boot passphrase and otherwise joins the same workspaces with the same permissions.

Make system experiments deliberate

The complete system is sealed in normal use. Package experiments run in a work layer that can be inspected, kept or thrown away. Specific administration uses named operations rather than a generic “anything as root” prompt.

Replacing the kernel or a sealed system file requires Unlock system. That does not delete personal data. It records that the machine is unlocked so a collaborator can distinguish it from the verified state. Relocking restores the verifiable chain.

Wanting a package manager, a different font or a root shell for an experiment does not quietly turn off every other protection.

Inspect diagnostics before sending

Crash and usage reporting are off by default. A diagnostic report is assembled locally and shown before sending. The preview separates system versions, hardware details, recent logs, workspace metadata and content.

Document text, message contents, invite secrets and collaborator names are not included unless you add them. You can remove any file from the bundle, search the bundle for a name or path, save it locally, or send nothing.

The Forgejo tracker opens with the public alpha. Security reports use a private path that does not require publishing an unfixed problem.

Inspect the claims

These are versioned documents tied to releases. A security sentence with no way to inspect what it means is advertising.