Local-only Vault suddenly syncing to Anytype network after update to 0.54.0

Going beyond this bug into the larger conversation of ‘local-first’ vs. ‘local-only’ requires a much bigger and detailed explanation that doesn’t make sense in this setting. However, it is very important for us to clearly outline these differences, so I will take some time in the future to write a post about this.

I don’t want to leave you hanging though, so I will address some points now. Just be aware that it may not be as detailed or well-explained as you desire.

No. When syncing on our network, your data is essentially sharded and stored on multiple nodes. This means bits of your data is broken up and encrypted. In order to put these shards back together, you need to have a key—which only the user has. Any Network has a ‘backup’ of your data, however this is not what it looks like in the traditional sense due to the way our infrastructure is designed from a security and privacy perspective. It’s not a simple folder/zip file that can just be opened from our database, which is what it may be like in other apps. You can be sure that there is no way for anybody to access your data, in Anytype or outside us. This is the way end-to-end encryption works which is verifiable in our open codebase.

If you want to remove your account from the Any Network, then the most comprehensive method we have today is to export all of your spaces, create a new account, import it all into the new account, check that everything is ok, and then delete your old account. This will trigger account deletion from our servers in 30 days. This is the best we can do today to mitigate this issue. If you’d like to expedite this, then we can try to coordinate this directly, to locate your account and delete it. However, it’s worth noting that taking this step will not make a meaningful difference to your data security or privacy. I outline the reasons below.

Again, we apologise for this bug, as it was not intended to be the case. It’s worth noting that when selecting ‘local-only’ mode, the app prompts warnings that it is an experimental mode because we are aware of the many issues that users may run into when in that mode. For example, a reddit user ran into data corruption issues and wanted us to diagnose/resolve it, but it was very difficult to do so because they were in local-only mode. Again, it doesn’t make the bug ok, but it is not a mode that we optimise for because the reasons I’ll outline below.

Local-first is exactly what Anytype is. Local-only is not the same thing, they are not synonymous terms, and Anytype does not strive to be ‘local-only’. Cloud-first apps (which is the default these days people are used to) means that all of your data is stored on the cloud/servers, and you cannot access it without an internet connection—because your data is not stored on your device. Local-first (which is Anytype) means that all your data is stored on your device, and you can access it even without an internet connection—because the network is only required for syncing, not access. This is why it’s termed ‘local-first’ and not ‘local-only’. Anytype was never designed to be a ‘local-only’ app, the vision of local-first is based on data sovereignty with connectedness—not data isolation.

Indeed, you are both right that these terms are not well-known or understood by the general public. If the expectations of users of ‘local-first’ means that no data ever leaves their device, then there is a lot more work to do on education. Although they are not terms we invented, we do use them because they are used by the greater software movement— this Ink & Switch article is a great definition for it. Within the confines of this software conversation, Anytype is indeed local-first but I 100% understand that not everybody understands its distinction with local-only.

This conversation is much too large to explain here, so I’ll give the high level points.

  1. There is no meaningful security or privacy benefit between local-first and local-only. It seems like on the surface that ‘local-only’ would be more secure and private, but this is based on intuition not the reality of security and privacy threats. Local-only mode actually comes with many distinct drawbacks, the most obvious being no syncing and no collaboration. This is why we call it an experimental mode. Users will go into local-only looking for tangible security and privacy benefits, but they won’t really get any and mostly suffer notable tradeoffs.
  2. There are meaningful benefits between local-first and self-hosting, such as infrastructure cost control, but that is a different conversation. Even though self-hosting is great, it also comes with the tradeoff of not being able to collaborate with any Anytype users outside of their self-hosted network. All models have their tradeoffs.
  3. The reason why we don’t make ‘local-only’ an option as default for users is simply because most people do not understand the difference. On the surface, it seems like you’re gaining big security and privacy benefits, when this isn’t really true. If users want an app that is entirely designed to be local-only, offline, and no collaboration—then Anytype is a poor solution. Many of the challenges we face are explicitly because we want to address real-time collaboration in this context of data ownership.
  4. We can maybe do a better job with educating users with explanations in apps, but frankly I’m not sure that’d help because most people skip through long explainers. And this topic cannot be explained in short.

Yes, you’re right that you did not want your data to be synced onto the Any Network. Again, we 100% recognise this as being an error and a mistake on our part. No excuses. However, I bring up the same point which is that there has been no compromise in your privacy or security in this situation—your data has not been breached. On the Any Network, your data is sharded and encrypted across our nodes, and it is not possible for anybody to access them. If you want to perform the account deletion process, you are 100% welcome to. However, it’s worth pointing out that this doesn’t actually change your privacy or security in a meaningful way (you’re not more/less likely to be exposed than if you kept your account). However, we recognise that this may feel a lot better for you, so that’s why we’ve provided clear steps for you to do so.

We can reiterate that your data and our encryption methodology is secure, however that’s just ‘us’ saying stuff that you might not trust. The way you can verify the security of your data is exactly why we have an open codebase: anybody on the planet can check to see how data is handled on Anytype—from that perspective the community at large certainly can verify that it is ‘secure’.

I 100% recognise that this is a distressing, annoying, and frustrating experience. I hope none of the above explanations are seen as deferring blame or making it sound like this bug was ok. It’s not. However, I provided those explanations in spirit of bringing to light the concepts behind the technology and to answer your questions.