Restore EteSync (Calendar/Contacts Sync)

I think that this reflects your experience. So yeah, there are some issues that you and a few others experience that have not been addressed. I also agree that the iOS application is not great and requires workarounds (those are heavily documented) because iOS is buggy and limited. It’s not unreasonable to expect support, I personally provide support to 5-10 people a week. It is, however, unreasonable to expect everyone to get personal support. You can also contact the EteSync community and get help there (Matrix chan has ~160 ppl and daily activity).

Docker’s whole thing is that it’s an identical environment that you can deploy anywhere, and since it definitely works for at least one person (the Docker image has over 500,000 downloads), it’s most likely something you did wrong. I understand the guides may be a bit rough around the edges, but given the above it’s extremely unlikely that the problem is with the image (which btw, is maintained by the community).

Right, that’s exactly what I’m saying…hence my suggestion that PrivacyGuides add a disclaimer stating that there may be issues, and they are not being addressed. Again I’m not really sure what (if anything?) you’re disgreeing with here.

Gotcha. In that case maybe there should be a disclaimer to the website’s proclamation that “EteSync is very easy to use. Our app seamlessly integrates with your existing apps so you won’t even notice you are using it.”?

I never said that, and I never expected that.

If Matrix is the best way to get help then perhaps that should be linked under the “It doesn’t work” section of the FAQ instead of the Git?

Didnt work out of the box for me, like any other docker image but could definitely be a system difference. Docker isn’t magic. I am not saying its easy to make something like this. Surely not.

I agree that EteSync is still the best solution for syncing contacts/calendars/tasks privately, regardless of how recently the apps have or haven’t been updated. Proton Mail doesn’t actually encrypt your contact names and email addresses.

When compared to the other recommendations on the website, it’s the only one that is actually syncing your information to your device, rather than just providing an app to access it (Proton Mail’s contacts for example, cannot be used to store and sync your Signal contacts, which are taken from your phone’s system contacts storage).

It’s also the only open source one. Or at least the server part. Proton Calendar’s apps are currently not open source though, and EteSync is.

Because the server is open source, it’s also self-hostable. This is not to say that you should self-host in order to not pay the very reasonable subscription fee of $24 a year, but for some people self-hosting is important, and if you already have the infrastructure, it makes sense to self-host it.

While it’s not recommended for contacts/calendar/tasks sync, EteSync is also better than Nextcloud’s syncing support. Both sync to the system storage, but this information is synced to Nextcloud in a completely unencrypted form, and it is also stored in an unencrypted form. This is true regardless of whether you use the end-to-end encryption add-on (don’t: Don't Recommend Nextcloud E2EE - #27 by ph00lt0), as Nextcloud simply runs a plain CalDAV and a plain CardDAV server.

While it may be true that “updates” are important for security, and by extension also privacy, there is nothing wrong with the current version of the apps (at least for my use case, which is an Android device, and multiple Linux devices), nor is anything to be gained to use by adding say, Material You support to the Android app. It just syncs your information after all.

To my knowledge, there are also no vulnerabilities in the apps that aren’t being fixed. F-Droid for example, labels apps with known vulnerabilities, and EteSync doesn’t have this label. If the server is being actively maintained, it should also be assumed that the chances of a vulnerability affecting EteSync users is low.

I understand if the team doesn’t particularly care about my opinion, as they have no reason to, but I don’t see the point of considering apps that haven’t been “recently updated” as worse than apps that actually have less privacy, less features, and less usability. I’m in favour of adding EteSync back to the list for these reasons.

Tl;dr: EteSync is still private, open source, and self-hostable. It syncs to the system, where the other recommendations don’t. And as Proton Mail’s contacts aren’t fully encrypted, and their calendar app isn’t yet open source, EteSync is the most private and open source option. Updates aren’t everything.


@anon62252234 I largely agree with your arguments for EteSyncs design and importance here, but I think you’ve missed the point of my post. The lack of updates isn’t necessarily an issue on its own; it’s an issue because the macOS/Windows and iOS clients have major reliability and usability issues (as described throughout the thread). Plus EteSync Notes is pretty clearly unfinished.

Privacy Guides shouldn’t be recommending things that aren’t reliable without a disclaimer, IMO. That’s the main conceit here.

As I’ve said a few times, on Android it works 100% as expected / advertised. So I think it should be recommended for Android, with a disclaimer about other platforms.

I don’t have experience with those clients, so unfortunately there’s not much I can say there. However, I didn’t say that EteSync Notes should be recommended, and I still don’t. Merely that the contacts/calendar/tasks syncing service, EteSync itself, should be recommended.

Also, you can have a disclaimer about reliability if you want. I’m not against that. But, at least EteSync actually has syncing. The other recommendations do not.

Fair enough. I agree that EteSync contacts/calendar/tasks should remain on the site, since it is a unique service, but with a disclaimer that it is not be reliable on macOS/Windows/iOS, bugs may not get addressed on those platforms … and that support may not be available, as evidenced by the main dev’s posts in this thread.

Thank you for the kind words, and I agree, that’s exactly what I think too.

Security updates, when ones are needed, will happen promptly. Though yeah, the app is safe and reliable, and it’s my daily driver too.


Not sure who needs to see this at Privacy Guides, but we’re all ready [even the original poster of this thread], to add EteSync back as a proper privacy recommendation.

You just listed the reasons why it won’t be recommended.

I think at this point if we were to restore the listing, it would only be for the EteSync android app. Reliability is important, and impacts directly the reputation of the site. If we recommend things that frustrate people, then people will be less receptive to all our advice.

It pains me, because I really do like EteSync’s, and I think it’s goal is a pretty awesome one, although I don’t use it myself, I am still looking at experimenting with it and keeping an eye on progress.

It may end up that EteSync makes sense for people who don’t really use desktop apps, or even iOS/maOS.

At this time EteSync in Google Play is still currently on SDK 29.

As of November 1, 2022 apps must be a minimum of SDK 31 in order to be updated, might this present an issue if a security vulnerability is discovered and the app needs to be patched urgently?


EteSync was contacted by the team before it was removed. This happened while I was still a team member, so I know it did, cause I was the one to contact them.

We were told that them not keeping up with modern targetSdk levels was not because they couldn’t do it (they said it’s a very simple process, which betrays a potential lack of understanding of how things work to me, as it’s not just about raising the targetSdk itself, but also ensuring that your app fully supports it, and that the required changes have been made to be able to support it well).

I’d asked them about this because they made a release on F-Droid, but not Play Store, and was wondering whether the reason for that was that they were unwilling to raise the targetSdk or something else.

The reason they gave me for not pushing an update to Play Store was that they didn’t have a workstation to build the new version on. shows 10K+ downloads. That is a lot of potential users who are not getting a new update because the development team is not doing what’s necessary to support all of their release channels, which I find unacceptable, personally.

Privacy Guides should maintain a high standards for projects they recommend, and Etesync is currently not meeting those standards.


@tasn what do you think of this?

@matchboxbananasynergy, “contacted by the team before it was removed” is a bit of a strong statement. We weren’t told not updating the Android app on the play store will lead to removal. We got an email asking why we haven’t updated the Play version when updating the f-droid one, we replied with:

We haven’t released a play version because it’s a bit more of a pain, not because of the SDK update. That one is super easy to update.

We never heard back after that. No additional questions, comments or anything.

The not releasing for the play store was because of issues with the local development environment at the time, combined with the fact that the changes weren’t that significant in that version to be worth it. We never talked about bumping (or not) the target SDK, though that doesn’t matter either.

That is correct. You weren’t told that your project was being removed, because that was not the purpose of my reaching out to you.

Keep in mind that EteSync was removed from Privacy Guides after I left the team.

I sent the first e-mail, got a reply that was lost because of an unfortunate situation with the team’s e-mail system, and I believe that a reply must have been sent to you after that, though I wasn’t the one to send it out, due to previously mentioned team e-mail situation. Whether that other team member actually did or didn’t; I do not know.

If I was still in the Privacy Guides team for the actual removal of EteSync, I would have reached out to you to see where you are with that and notify you that the team may be considering removing your project.

That said, I fail to see how supporting all of your project’s release channels appropriately is something that Privacy Guides should have to threaten you with removal into doing. Basic app maintenance is the bare minimum. That includes keeping up with new targetSdks as they come out as well as other things, depending on the project.

I did state in my previous post that you provided reasoning for not updating the app through Play Store, and that it was not due to not being able to/willing to update the app’s targetSdk, but that it had to do with your development environment.

When was that? I see here that the latest version landed on F-Droid on Septemeber 18, 2022. You couldn’t push the new update then, because of the local development environment. Is that still the case? Are you planning on delivering the changes of this latest update to your Play Store users? Will you bump up the targetSdk so that you can upload new versions to the Play Store going forward in the first place? Can EteSync commit to keeping all of its release channels up to date, something which I find to be the bare minimum?

I’ll reiterate once more just to be clear that I’m not part of the Privacy Guides team at this point, so just like it wasn’t my decision to remove it, it’s also not my decision to add it back, but I felt like I had the responsibility of posting here seeing as I was the one to initially notice the discrepancy for the Android app and reach out to you.

Concrete answers to the above questions would help the Privacy Guides team get a better sense of your project’s state, and decide what they want to do from there.

Thanks for hearing me out, and I wish you the best of luck!


@tasn Do you have a response to this?

As a current EteSync customer I’d like to see an Android listing come back, but the other platform support remains poor. Thunderbird extension was also promised but never came to fruition, whilst etesync-dav takes up too much RAM and still has slow/unreliable syncing. Unless it dramatically improves I’ll probably switch to Thunderbird sync when that’s released.

Btw, we just sent the new app (with the updated targetSDK) for approval to the play store. The ball is now in Google’s court.

Thunderbird extension: Yeah, trust me, I’m more bummed than anyone else about this. We worked hard to secure funding to get someone (a Thunderbird add-ons expert that maintains very popular and relevant add-ons) to build it, but they kept on disappearing and in the end just didn’t do it. :expressionless:


Hello all, I’m here to make a u-turn on my previous statements, and to request that this be formally rejected (cc @dngray).

Let me explain why: the Android app was updated to use the latest SDK, but that’s all. It still has no dark mode, no monochrome icon. This in and of itself is no issue, but it’s just part of what shows that the app is very outdated. Additionally, the version that updated the SDK also broke tasks syncing. This was fixed, but shows a clear lack of testing.

Now, it seems that syncing with the Android app at all doesn’t work. I have had this issue too. I tried multiple versions of the app, adding the account, removing it, etc. Nothing works. At this current point in time I simply have exported my data (which I had to do through the bridge, since no other client has this functionality) and have my contacts imported locally (since that information is used by email clients and Signal, etc.). I’m going to have to figure out what to replace EteSync with, if anything (could just stick with local stuff, although my tasks apps don’t support import/export).

Speaking of the bridge, it hasn’t been meaningfully updated in years. It is also impossible to install it from pip or compile the binaries. This is an issue because the last amd64 binary is from a year and a half ago, the last arm64 binary is from two and a half years ago, and it should be possible to compile the binaries, as it is open source software. The bridge does technically seem to work, using those years old binaries, but this is not a maintained project.

It doesn’t seem @tasn has time to work on EteSync right now, which isn’t an issue of course. But no one should be paying money to use this software, which is definitely private, but probably not at all secure after years of not being properly maintained. And, it’s only useful if you can actually get it working in the first place.

Tl;dr: EteSync should under no circumstances be recommended, and it’s ridiculous to even continue discussing it. I propose that this be rejected.

1 Like

We wouldn’t be evaluating that.

It wasn’t a priority and while polish is nice, actual functionality and stability are the main two things we look at. While EteSync may not be a part of our recommendations currently, we still actively are watching it, as there really isn’t anything else in that space.

We refrain from adding things to Privacy Guides which are likely to frustrate users looking for more private solutions. It is the main reason why after numerous cleanups we don’t simply list anything that “sounds good” like we did in the Privacy Tools days.