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
