Replying to Avatar daylightco

Basically, we've legally been advised by our lawyers that we had to update the policy for specific different regions (Switzerland, Europe, California) and because we've reached a critical mass of people, and to cover our bases for fundraising. As part of this, we had to be more specific about all the data that lives on our servers is. We never intended to imply this kind of data gets used for any other purpose than error logging and loading and syncing the content in your library. Nor will it ever be used for any other purpose.

If you compare it with the prior policy, you will see they are identical on this point. It's inconvenient that the standardized nature of these policies has implications other than what I'm describing, but it's very expensive to change and we have to be judicious about where we direct our resources. When the time is right, I'm sure we will make all these distinctions more explicit. Again, I'm not a lawyer, but I can assure you that as a technical fact, and in terms of the 13 people who work at this company, there isn't any intent or implementation that behaves the way you're concerned about.

A last statement about encryption since you also mention it: the data is not encrypted at rest, so that we can process it for title-generation, length, PDF generation and so on, and so backups and syncs are easy. Every piece of data is e2e encrypted in the same way Signal messages and so on are: over https, the same way your banking information is protected. To encrypt at rest is a major technical undertaking we do intend to get to eventually, and we have put in work there, but it's going to take more time. If you're curious, see https://en.wikipedia.org/wiki/Homomorphic_encryption

Re: privacy, you're saying "trust us". (at the same time as you're on nostr attempting to appeal to a "don't trust, verify" crowd). I understand the legal and resource reasons why you are doing so, but at the end of the day it's still "trust us, we'll be good".

> the data is not encrypted at rest, so that we can process it for title-generation, length, PDF generation and so on, and so backups and syncs are easy

Why not do that generation on-device and sync encrypted data? Is processing data for "title-generation" and "length" really so resource intensive that it must be done in centralized servers? If so, why not allow users to self-host their own services for providing this computation to themselves? Obsidian Sync works this way - that is, you either sync _encrypted-at-rest_ data with the for a fee, or you provider your own sync service - and I've noticed you guys like to be seen as travelling the same seas as Obsidian.

Reply to this note

Please Login to reply.

Discussion

with THEM* for a fee (Obsidian's sync service)