Hi there,
recently there has been a post here about Colota and thought you might be interested in a short summary about Colota.
I am tracking my position since several years now mainly with Owntracks (and now Colota) and a simple postgres DB/table.
I am a fan of the indieweb and eat what you cook and with already some million location points collected I recognized some pattern in existing GPS trackers I wasn't happy about:
- Battery consumption
- Duplicate points while staying in the same location for a long time
So I decided to build my own GPS tracker and called it Custom Location Tracker.
Improved battery consumption should come from disabling GPS entirely in so called "geofences" which are basically circles you draw on a map in the app. With GPS disabled in these you also won't get duplicate points while staying at e.g. home or work.
The app is still quite new (actively developed since early 2026) but has already quite a lot of features which basically all came from user feedback. E.g.:
- Automatic Tracking profiles which apply different tracking settings while e.g. being connected to Android Auto, moving slower than 6km/h or while the phone is currently charging.
- The app works fully offline (map will not be visible then) but you can predownload map tiles from a tile server I selfhost or use your own tile server.
- You can define how locations are synced to your backend. E.g. only for a specific Wi-Fi SSID every 15min, once a day or with every location update.
Overall the app's focus should move to be a mobile location history app. So basically Google Timeline in a mobile app which also supports selfhosted backends (as backup).
The app is fully open-source AGPL-3.0, has no ads, analytics or telemetry and only sends data to your own server (if you want to).
You can download two versions.
- Google Play store which uses Fused Location Provider and therefore uses Google APIs. Also works with the sandboxed version by GrapheneOS and microG.
- FOSS version which uses Android's native GPS provider with a network location fallback. Available on IzzyOnDroid and hopefully someday on F-droid.
Both can be also downloaded directly from the repo.
E2E encryption is specifically designed for the third-party problem. Encrypting so a middleman can't read your data.
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.
I don't think it's the job of an Android app to protect a server from government hacking attacks.
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.
Fair enough, thanks for the feedback.
It can't prevent the hack, it absolutely can protect the data, and make it useless. That's the entire purpose of encryption.
Again, it's not supposed to.
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.
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.
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.
You don't have to. You just have the app encrypt the data before it's backed up and exported.
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.
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.
Have a good day!
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.