

They all suck and should be avoided.


They all suck and should be avoided.


You entered a thread explicitly about E2E encryption started by ShortN0te
That person replied to a thread I started, not the other way around. It was never about E2E. It was always about encrypted backups.
It could have a encrypted backup feature but it won’t change it’s fundamental purpose
It’s not supposed to. It shouldn’t.
They’re meant to be workable in other tools like QGIS, Strava or Komoot. Encrypting them would break that entirely.
Then make it optional? Or don’t, I don’t care.


deleted by creator


Halfway through you shifted to encrypted local backups
I never shifted anything. I was talking about encrypted backups on a server. These can be encrypted locally before being synced to a server.
you first called ‘single-party encryption’
Nope, you literally just made that up. I didn’t say that and I don’t even know what that means.
I said it wasn’t realistic in the context of the selfhosted backends we were discussing.
…but it is.
And yes, lots of apps do encrypted backups because they are backup apps. Colota isn’t.
My suggestion was that it could be…
The existing export is for tools like QGIS or selfhosted backends and encrypting that data would break that use case entirely.
You already have local backups that could be encrypted and then synced to a general storage server.
Encrypted import/export for backup is a separate feature that doesn’t exist yet, so there’s nothing here that’s badly implemented.
I said literally nothing about your implementation. You’re imagining things. Please read more attentively.


I don’t know what you want man
I honestly don’t know how to be more clear about this. It’s not complicated. I want client-side encryption, man.
i didn’t realize this was one of those “digging my heels in because I don’t know how to be wrong” threads
LOL I didn’t know that either, but here you are!


You just asked the creator of an exclusively client-side app whether they support encryption.
Client-side encryption is not a novel concept.
something like Keepass where the file itself is encrypted, you have to use some form of auth to decrypt it on use
That’s significantly more complicated and time-consuming.


No one is talking about a phone or a PC, we’re talking about a server.
Also phones and PCs are only encrypted at rest.


I already explained several times why that’s not realistic
You haven’t. You’ve only explained why you don’t want to do it, which is fair, but you keep presenting as if it’s not possible, which is not accurate. Lots of apps can and do create encrypted backups.


It’s not that I don’t want. I can’t implement it because I don’t offer a server.
You don’t have to. You just have the app encrypt the data before it’s backed up and exported.
you are not understanding mine which is the actual use case of the app
I understand the usecase but you’re acting like you don’t understand the purpose of encryption, for some reason suggesting that it’s supposed to prevent hacking, when that is not at all what it does.


If a server gets hacked where a user sent data from Colota there is nothing the app can do about it or to prevent it
It can’t prevent the hack, it absolutely can protect the data, and make it useless. That’s the entire purpose of encryption.
I don’t think it’s the job of an Android app to protect a server from government hacking attacks.
Again, it’s not supposed to.
Also the app is offline-first. There is no server needed unless the user specifically configures that.
The server is needed for the same reason a server is needed for anything: to back up the data.
If you don’t want to implement it, that’s fine, I respect your decision, but there’s no reason to come here pretending not to understand its purpose.


There’s no third party to encrypt against.
Encryption does not exist for third parties. It exists to protect sensitive data from malicious or state actors who might hack your server and steal the information for various purposes. Here in the US law enforcement is free to hack and steal and demand whatever they want.
All these backends would have to support the same decryption which Colota offers, which is not realistic.
I would prefer single-party encryption vs. integration, personally. Could make it optional.
I appreciate your contributions but for me personally this is a dealbreaker.


Thank you for sharing. Is this information encrypted? Doesn’t seem safe to use without that…


This marks the day they lost me as a long-term customer. Perhaps ought to have happened earlier, but for me, it happened today. I encourage others to consider the same.
I mean I’ve never been an Apple customer. At least not since the OG iPods. But what company are you going to move to that wouldn’t do the exact same thing in that situation?
Apple is uniquely shitty in having endless contempt for their own customers, which is why I’ve always avoided them. But this just seems like kind of a weird “last straw”. But hey, anyone boycotting Apple has my support.


In order to find out, they’d have to also be using Meta, which is embarrassing enough in itself so they shouldn’t be talking.


Yes, that was my entire point.


You can’t though. That was my entire point.


Well that’s exactly my point.


Honestly I would probably pay for it and be happy but Premium doesn’t solve many of the problems that still exist:
etc. etc. All problems Google could solve easily but simply won’t.
I mean “its back” in the sense that demand is rising for nostalgic purposes. Not in the sense that anyone wants a new one.