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.
https://play.google.com/store/apps/details?id=com.etesync.syncadapter 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.
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.
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.