Transparency
Transparency
Product pages are written to impress. This one is written to be checkable. Everything below is a real weakness of NeyLivo, listed by the project itself.
Last updated: August 12, 2026 · NeyLivo 1.563.0
Why this page exists
A privacy product that hides its own limitations is asking to be trusted more than it deserves. People make decisions based on what a page like this says — whether to send a document, whether to have a conversation. If we get that wrong in our favour, the cost is paid by someone else.
So: everything here is a thing we would rather not have to write.
Open weaknesses
| Weakness | What it means | State |
|---|---|---|
| Attachments are in public storage | Files sent without attachment encryption can be downloaded by anyone who has the link, without signing in. The database is protected by access rules; this storage is not. Turning on attachment encryption in Settings fixes it for your direct messages today. The proper fix — closing the storage and moving to signed links without breaking the links already embedded in old messages — is planned in stages, and the first, harmless stage is to stop the bucket being listable at all. | Being fixed |
| Encryption is off by default | End-to-end encryption for messages, attachments and calls exists, works and is documented — and all three switches start off. Privacy that only reaches the people who go looking for it in the settings is privacy that most people never get. | Open |
| Group chats and channels are not end-to-end encrypted | Only one-to-one direct messages are. Group encryption is a different and much larger problem — key distribution, members joining and leaving, multiple devices — and it will be designed properly before anything is written, not improvised. | Design stage |
| Call encryption has never been proven in a real call | The code path is covered by tests, and the library calls were checked against the library’s own source. But nobody has yet made an encrypted call between two real devices and confirmed it. Until that happens it is labelled experimental everywhere it is mentioned. | Unverified |
| No Content-Security-Policy | There is no known way to inject code into the app today — messages are rendered as React nodes, and there is no raw HTML insertion anywhere in it. CSP is the second line of defence that catches the mistake nobody has made yet. Adding it needs care because plugin pages, embedded players and emoji load from several places. | Open |
| Emoji images come from a public CDN | The interface contains emoji, so a third party receives your IP address on every launch without you doing anything. The app deliberately avoided this for fonts, which are bundled; emoji should be bundled too. | Open |
| Minimum password length is six characters | That is the platform default and it is too short. | Open |
| No two-factor authentication | Trusted devices and a recovery code exist, and they help, but they are not the same as an authenticator app. | Open |
| No external security audit | Nobody outside the project has reviewed any of this. Everything on the security page is our own reading of our own code — which is exactly why the code is public. | Open |
| No open source licence yet | The source is public and readable, but it carries no licence, which technically makes it source-available rather than open source. That is an unfinished decision, not a stance. | Open |
Shipped but not verified in real use
Some things are released, appear to work, and have never been confirmed by two people actually using them at once. They are not presented as finished:
- End-to-end encrypted calls — needs two people and a live media server to verify.
- The Android update installer — the native code was checked line by line against the platform sources, but has never been run through a real update on a real phone.
- Some notification paths that need a second person and a closed window to test.
Where the app itself knows something is unproven, it says so in the setting rather than in a footnote.
What has been dealt with
Some earlier problems are closed, and it is only fair to say so: the database access rules were tightened repeatedly and are now tested against a real Postgres on every change; push notifications used to let any logged-in user send a fake system notification to anyone and no longer do; a personal GIF collection used to be visible to everyone and is now private; message length is no longer visible through ciphertext size.
How to check any of this
Everything above points at code you can read. The repository is public, the technical audit with file references is published in it, and the database access rules have a test suite that plays several users against a real database.