Your work should be protected without becoming inaccessible to you.
Security in a file workspace is not one control. It is access, file integrity, recoverable history and honest sync state — and the product is only as trustworthy as the weakest of them.
What follows is how Eiswe is designed to behave, stated plainly. Where a control has not been confirmed against a shipped build, it is marked rather than claimed.
Damaging your work counts as a security failure.
Most of what threatens real work is not an attacker. It is a conversion that quietly dropped something, an edit written into the wrong version, or a save that silently produced a file the original application can no longer read properly.
Eiswe treats those as the same category of problem as unauthorised access, and the design answer is the same: fail visibly rather than proceed quietly.
A file should never be in a state you cannot name.
Two questions decide whether work is safe: can I get the previous version back, and do I know where this file actually is right now. Both should have a visible answer.
A change creates recoverable history rather than replacing what came before. A previous state can exist independently of the current one, so a mistake, a bad import or a sync problem all have the same remedy: go back.
You should never have to guess whether a file exists only on this device, has reached the server, or has diverged somewhere else. The state is stated, not implied by a spinner.
Offline does not mean unprotected.
Where a platform supports local work, losing the connection does not stop the work or put the file in doubt. Changes queue, then synchronise when they can, and anything that diverged is surfaced rather than resolved behind your back.
The honest corollary: a local change is local until it has actually synced. Eiswe says which of those it is instead of implying everything is already safely elsewhere.
Access is something you do, not something that happens
Storing a file in Eiswe does not share it. Sharing is a deliberate action with a visible state on the file itself, and it can be taken back.
The boundary around your account
Two areas where a vague claim is worse than none: how your account and sessions are protected, and how the production infrastructure behind them is controlled.
The specifics — authentication and session handling, account separation, transport security, environment and storage boundaries, secret handling and dependency checks — will be published here as precise statements once each is confirmed against the shipped implementation, rather than described in advance.
What security cannot honestly mean
No product can promise no bug will exist, that every format is perfectly preserved, that all platforms behave identically, or that no future attack succeeds.
What a product can do is fail visibly and safely — and say which of those it is doing.
Protection is not the same as capture
Work is not made safe by being difficult to remove. Export stays part of the model, and standard files leave as standard files.
Security controls should protect access to your work, never your ability to take it with you.
Found a security issue?
Contact us privately before disclosing it anywhere else. Include what you found, how to reproduce it, and where you were looking.
Reports are read by the people building Eiswe. Please give us time to look into it before making it public.