Thanks for the kind words! Vehicle/trip categories (car, bike, train, walk) + per-vehicle tracking is a great idea and fits well with the profile concept. Personally, I also want to skip other (activity) tracking apps which is the reason I also would love to have these features. Added the feature requests to the backlog. Thanks for taking your time trying out the app and giving feedback!
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 entered a thread explicitly about E2E encryption started by ShortN0te and introduced “single-party encryption” or which later turned out to mean encrypted backups.
Nope, you literally just made that up. I didn’t say that and I don’t even know what that means.
“I would prefer single-party encryption vs. integration, personally. Could make it optional.”
You wrote ‘I would prefer single-party encryption vs. integration, personally’ in this exact thread. That’s not something I made up.
…but it is.
I’d genuinely like to understand how.
My suggestion was that it could be…
This app has a specific purpose. It could have a encrypted backup feature but it won’t change it’s fundamental purpose which is viewing the location history.
You already have local backups that could be encrypted and then synced to a general storage server.
The exported files are not designed as backups (even though they are being used as ones by existing users). They’re meant to be workable in other tools like QGIS, Strava or Komoot. Encrypting them would break that entirely.
I said literally nothing about your implementation. You’re imagining things. Please read more attentively
Fair point. I misinterpreted that. No need to get personal.
New day, new answer!
You started this conversation in a thread about E2E encryption and I responded in that context. Halfway through you shifted to encrypted local backups which you first called ‘single-party encryption’ and that’s a completely different thing. If that had been your original point we could have skipped this entire exchange. It’s a good idea which I already mentioned in the answer you replied to but you seem to have missed.
To clarify two things: I never said it was impossible. I said it wasn’t realistic in the context of the selfhosted backends we were discussing. Those are different statements. And yes, lots of apps do encrypted backups because they are backup apps. Colota isn’t. The existing export is for tools like QGIS or selfhosted backends and encrypting that data would break that use case entirely.
Encrypted import/export for backup is a separate feature that doesn’t exist yet, so there’s nothing here that’s badly implemented. It simply isn’t implemented at all.
By default this applications allows when adding a server, that the communication is not encrypted between the app and the server. This should be configured by default to enforce TLS encryption.
That’s not true. For public endpoints, HTTPS is enforced. You can’t use HTTP. For private IPs, yes HTTP is allowed. So “by default… not encrypted” is not correct and misleading.
That’s an interesting reading of what I said, but not what I said. I didn’t write that security doesn’t matter because the server is off. I wrote that when nothing leaves the device by default, there is no attack surface to secure. That is the definition of secure by default.
Secure by default means the default configuration is safe. By default, Colota stores location data locally and exposes none of it. If you believe that somehow fails the secure-by-default standard, I’d genuinely like to understand how.
If your actual concern is what happens once a user configures a server, that’s a fair discussion but it’s a different one. I already addressed that above and I’d be curious to hear a specific objection to that setup rather than a general claim that it’s insecure. Server compromise risk is inherent to every self-hosted service. That’s not a Colota flaw, that’s the model. And “users shouldn’t have to manage their own infrastructure” is a philosophical position, not a vulnerability. One that doesn’t really fit a tool explicitly built for people who want exactly that control.
You don’t have to. You just have the app encrypt the data before it’s backed up and exported.
I already explained several times why that’s not realistic for the selfhosted backends.
You could have just written at the beginning that you think it would be a good idea to implement (optional) encrypted backups Independent of the selfhosted backends. Then I would have answered, great idea!
But you continued to reply on a thread about end to end encryption where I specifically mentioned the selfhosted backends.
I understand the usecase but you’re acting like you don’t understand the purpose of encryption,
Have a good day!
It’s not that I don’t want. I can’t implement it because I don’t offer a server. You would have to address this to the backend developers (Dawarich, GeoPulse or even yourself) who actually store the data.
but there’s no reason to come here pretending not to understand its purpose.
I am understanding your point, but apparently you are not understanding mine which is the actual use case of the app and it’s workflows and therefore make it look like it would miss basic security patterns. The whole “location history” ecosystem stores plaintext coordinates.
Encryption does not exist for third parties.
E2E encryption is specifically designed for the third-party problem. Encrypting so a middleman can’t read your data.
It exists to protect sensitive data from malicious or state actors who might hack your server and steal the information for various purposes
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. Also you can create a backend which encrypts the data. Again: Colota does not offer a backend.
Here in the US law enforcement is free to hack and steal and demand whatever they want
I don’t think it’s the job of an Android app to protect a server from government hacking attacks.
I would prefer single-party encryption vs. integration, personally. Could make it optional.
I understand the concern. The tradeoff is that backends like Dawarich or GeoPulse need to read the coordinates to build timelines, detect trips, display maps, etc. Encrypted blobs would make the server a simple backup at which point the local auto-export to Syncthing/Nextcloud achieves the same thing without the complexity. For pure backup, the offline + file export workflow already covers that use case. Also the app is offline-first. There is no server needed unless the user specifically configures that.
I appreciate your contributions but for me personally this is a dealbreaker.
Fair enough, thanks for the feedback.
The default setting is that everything stays on-device. The user then can change the config to fit their own threat model, e.g. by adding a server, choosing HTTP for LAN, etc.
Probably phrased that wrong. There is no backup server. Users can create and add one if they like.
Colota offers out of the box file export (csv,geojson, gpx and kml) and supports hive_partitioning via variables in the endpoint (https://colota.app/docs/configuration/server-settings#url-variables).
Colota already uses WiFi for home detection (WiFi pause in geofence zones) and Android Auto/car mode for vehicle profiles.
How can it tell when you leave the geofence if the GPS is off?
GPS is only turned off by being connected to a WiFi or being motionless (or both) while being in a geozone. When wifi disconnects or/and motion is recognized the GPS starts again.
Bluetooth detection is the one thing that doesn’t exist. It could be a useful addition. I will note that. Thank you for the feedback!
I also agree with you both that location data is definitely personal data that should be protected. However, Colota stores data only on your own device and it’s never sent anywhere unless you configure a server and that server is out of Colota’s reach. End-To-End-Encryption doesn’t apply here since Colota is just one endpoint sending to the user’s own server. There’s no third party to encrypt against.
Colota is also meant to be an app which supports several “Google Timeline” alternatives like Dawarich, Reitti, Geopulse, etc. All these backends would have to support the same decryption which Colota offers, which is not realistic. You can also specify that data is only sent via an active VPN connection or just use it offline and use the built in file export as e.g. geojson.
Also Colota is a free and open source project. You can review the full source code to verify how your data is handled.
Thank you, really appreciate it! Glad to hear Colota is working well with Dawarich for you so far. Feedback and criticism are always welcome. Most of it has led to real improvements in the app. I think a casual forum thread is probably just not the best setting for deep technical discussions, where context shifts quickly, everyone has a different background and nuance gets lost.