Security & Privacy

Abolitus was built around a simple security position: your story, your characters, your prompts, and your provider credentials should not become somebody else's dataset just because you wanted a better chat client.

Most AI products ask you to trust the operator.

They tell you the service is safe, the logs are limited, support only looks when necessary, or training opt-outs exist somewhere in a menu.

Abolitus takes a harder line.

The service is designed so that the operator should not need ordinary access to your working creative data in the first place.

That does not make the app magical.

It means the threat model is explicit, the boundaries are visible, and the privacy promises are tied to architecture rather than to marketing language.

The Core Security Idea

The central rule is this: the browser is the trusted workspace; the server is not.

Your readable working environment lives on your device.

If you enable cross-device continuity, the material that leaves the device is supposed to leave in encrypted form rather than as ordinary readable application data.

This creates a very different trust relationship than a conventional hosted AI platform:

your local device is where readable workspace state exists,
the cloud sync layer is treated as transport and storage rather than as a normal transcript reader,
and the service tries not to become another inspection layer in your inference workflow.

What This Section Covers

This section explains the privacy model from several angles.

E2EE Architecture

Read E2EE Architecture if you want to understand where encryption begins, what gets protected, what the sync server can and cannot infer, and why recovery in a zero-knowledge system works differently from ordinary SaaS recovery.

Local CSAM Shield

Read Local CSAM Shield if you want to understand how Abolitus enforces one hard legal boundary without turning ordinary chat into a server-side moderation pipeline.

OPSEC

Read OPSEC if you care about the operational discipline behind a privacy-focused product, including hostile-backend assumptions and fingerprint-reduction practices.

What Security Means in Practice

Security in Abolitus is not only about encryption algorithms.

It is also about deciding which category each piece of information belongs to.

Examples:

your current chat text is working creative data,
your character library is long-term creative data,
your provider keys are high-sensitivity credentials,
and wallpaper or theme choices are mostly local comfort settings.

Those categories should not all be treated the same way.

Some things should sync, some should stay local, and some should never casually pass through product infrastructure at all.

What Abolitus Tries to Protect You From

This design is mainly meant to reduce exposure to risks such as:

routine server-side inspection of chat history,
centralized storage of readable roleplay logs,
support workflows that depend on collecting your raw private scene text,
cross-device sync systems that quietly turn into plaintext backup systems,
and accidental leakage of provider credentials through platform infrastructure.

What Security Does Not Magically Solve

No privacy architecture erases every risk.

You should still assume the following remain true:

if your device is compromised, your local readable workspace may be exposed,
if your chosen provider logs prompts on their side, that is a provider-level risk,
if you lose unrecoverable recovery material, a zero-knowledge system may not be able to restore you,
and if you export plaintext files manually, those exports are only as safe as where you store them.

In other words, Abolitus can reduce trust in its own backend, but it cannot repeal endpoint risk or provider behavior.

The Most Important Privacy Caveat

The system is safest in local inference mode.

If you use a cloud provider, the prompt content still goes to that provider for inference.

The stronger claim is narrower:

Abolitus tries to keep its own backend out of ordinary readable inference traffic.
Sensitive keys and local vault material remain client-side.
Cloud continuity is supposed to move protected state, not normal readable transcripts.

A Good Reading Order

If you only want the practical version, read in this order:

If you want the full picture, read all three pages in this section before deciding how much cloud continuity you want to enable.

Read LLM Connections for the clearest local-versus-cloud provider explanation.
Read Billing and Premium for the difference between continuity features and provider billing.
Read Desktop Tunnel if you want remote access without giving up the local-hosting mindset.

Security & Privacy

On this page