Disclosure: I work at Anytype. This is the architectural bet we took, so I'll answer your four problems directly.
Premise: treat it as certain that the server will eventually be compromised, subpoenaed, or misconfigured. So the server must hold nothing that can be decrypted or linked to a specific user's content. Users hold their own encryption keys, the server stores ciphertext, and there is no UUID→identity mapping at the sync layer. Sync runs over any-sync, which is peer-to-peer-capable; intermediate nodes see ciphertext.
On your four problems:
1. O(x*y) joins - pushed to the client, because the server can't decrypt enough to do them.
2. Offline members - eventual-consistency sync and CRDT.
3. Client-side theft - if an attacker has the user's keys, they have the data. Intentional: no server-side gate to break means no server-side gate to exfiltrate at scale. We're considering optional 2FA at the infrastructure layer as an additional barrier to data retrieval.
4. Unwanted modifications - content is signed with user keys and validated on read.
Real cost is on the product side: no server-side AI over your notes, no server-side full-text search, slower cold-start, and harder to build product analytics (no access to user data). Granular ACLs are also harder — permissions are enforced by key possession, so revoking access often requires key rotation rather than a permission-flag change.
But the exact bug this post is about (a server endpoint that maps a public UUID to an email) is structurally impossible in this model, because there's no such mapping on our servers to misuse.
any-sync and our data format (any-block) are MIT, if you want to poke at how it works: https://github.com/anyproto
Great project! I’ve had a similar experience with Rewind and the related privacy concerns. A quick thought: if I recall correctly, Rewind performs OCR locally, so it only needs to send textual data. Since you’re focusing on macOS, you could rely on VNRecognizeTextRequest and skip the extra OCR complexity. It might also help to detect and mask sensitive information with lightweight models (e.g., BERT), especially when leveraging cloud-based AI.
Self‑hosting swaps one risk for another. A cleaner option may be local‑first apps that speak an open sync protocol: your data lives on your phone/laptop/homeserver; an optional, end‑to‑end‑encrypted relay just moves opaque blobs for backup and multi‑device access.
Why this matters: the No. 1 failure I see isn’t servers getting hacked. It’s users losing the only copy of their files.
* ~70 million phones are lost annually; most are never recovered. https://snohomishcountywa.gov/Archive.asp?ADID=543
* Consumer hard‑drive AFR hovers around 1‑2 %—≈7 % fail within five years. https://blocksandfiles.com/2024/05/02/disk-failure-rates-in-...
* 29 % of people have already suffered data loss from deletion, ransomware, or disk death. https://www.worldbackupday.com/en
With odds like these, an off‑device, unreadable backup is basic hygiene, not a luxury.
Disclaimer: I work on Anytype, which follows this model: local ownership, open‑source sync protocol, source‑available clients.
Thank you, I made an update to the original post with your explanation, and because you stated that the output was a pure hallucination, I also attached one of them.
In one of the responses, it provided the financial analysis of a not well-known company with a non-Latin name located in a small country. I found this company; it is real and numbers in the response are real. When I asked my ChatGPT to provide a financial report for this company without using web tools, it responded: `Unfortunately, I don’t have specific financial statements for “xxx” for 2021 and 2022 in my training data, and since you’ve asked not to use web search, I can’t pull them live.`.
In one of the responses, it provided the financial analysis of a not well-known company with a non-Latin name located in a small country. I found this company; it is real and numbers in the response are real. When I asked my ChatGPT to provide a financial report for this company without using web tools, it responded: `Unfortunately, I don’t have specific financial statements for “xxx” for 2021 and 2022 in my training data, and since you’ve asked not to use web search, I can’t pull them live.`.
No, definitely not the empty string hallucination bug. These are clearly real user conversations. They start like proper replies to requests, sometimes reference the original question, and appear in different languages.
Reported a flaw to OpenAI that lets users peek at others' chat responses. Got an auto-reply on May 29th, radio silence since. Issue remains unpatched :(
Avoided their bug bounty due to permanent NDAs preventing disclosure even after fixes. Following standard 45-day disclosure window—users should avoid sharing sensitive data until this is resolved.
Premise: treat it as certain that the server will eventually be compromised, subpoenaed, or misconfigured. So the server must hold nothing that can be decrypted or linked to a specific user's content. Users hold their own encryption keys, the server stores ciphertext, and there is no UUID→identity mapping at the sync layer. Sync runs over any-sync, which is peer-to-peer-capable; intermediate nodes see ciphertext.
On your four problems:
1. O(x*y) joins - pushed to the client, because the server can't decrypt enough to do them.
2. Offline members - eventual-consistency sync and CRDT.
3. Client-side theft - if an attacker has the user's keys, they have the data. Intentional: no server-side gate to break means no server-side gate to exfiltrate at scale. We're considering optional 2FA at the infrastructure layer as an additional barrier to data retrieval.
4. Unwanted modifications - content is signed with user keys and validated on read.
Real cost is on the product side: no server-side AI over your notes, no server-side full-text search, slower cold-start, and harder to build product analytics (no access to user data). Granular ACLs are also harder — permissions are enforced by key possession, so revoking access often requires key rotation rather than a permission-flag change.
But the exact bug this post is about (a server endpoint that maps a public UUID to an email) is structurally impossible in this model, because there's no such mapping on our servers to misuse.
any-sync and our data format (any-block) are MIT, if you want to poke at how it works: https://github.com/anyproto