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.
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.
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.
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.
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.
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.
I never shifted anything. I was talking about encrypted backups on a server. These can be encrypted locally before being synced to a server.
Nope, you literally just made that up. I didn't say that and I don't even know what that means.
...but it is.
My suggestion was that it could be...
You already have local backups that could be encrypted and then synced to a general storage server.
I said literally nothing about your implementation. You're imagining things. Please read more attentively.
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.
You wrote 'I would prefer single-party encryption vs. integration, personally' in this exact thread. That's not something I made up.
I'd genuinely like to understand how.
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.
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.
Fair point. I misinterpreted that. No need to get personal.
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's not supposed to. It shouldn't.
Then make it optional? Or don't, I don't care.
If the target server is compromised or taken by LEA the data is gone.
Laying the responsibility into the hands of the user is not ok for such an data aggregating service. Such highly critical, private and intime data should be protected and secure by default.
Not even transport encryption is enforced in the project. At first glance, http is allowed on local connections?!? Generate a self signed SSL cert on start and pin it in the app. Easy.
It is no excuse that other services do not follow these state of the art protection measures.
Most projects in the self-hosted space put the load of transport security on the user or another system, including big ones like Immich.
Not sure why you've chosen to be indignant about this particular implementation.
We are talking about a tracking App. Most selfhosted projects do not store such private data. You may can mage the argument for immich but only for ppl who take a picture every 5 min.
That is patently not true, in the self-hosted space or otherwise.
If you want to take some kind of the security stance on pii or other personal data, you may want to take a look at the app's workflow first before making declarations of "inadequate security". There are other considerations than simply slapping a self-signed cert on data in transit (or at rest, for that matter). URL encoding, secrets management, api structure, etc.
If you want to architect the security of your data using this app, it is much easier to simply encapsulate or encrypt the transport yourself. A VPN would be fine. An authentication proxy would be another.
Ultimately, your comments on security here need more and better context to meet a reasonable threshold of confronting the dev on it.
In security and development there is a statement, called "secure by default". That means the default settings are secure. This would encapsulate something like enforced Transport encryption.
Does this mean that the config can not be changed to fit the thread model? No.
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.
Thats like saying:
"The SSH Server configuration does not need to be secure because the SSH Server is turned off by default"
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.
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. If someone would want to disable dis behavior and allow unencrypted communication, then this should take extra steps.
As i commented somewhere else, to say that since it is turned off it is secure by default, is like saying: "The SSH server is turned off by default so the configuration that comes with it does not need to be secure when shipped"
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.
Yes, this is what we're discussing... Are you a bot? Or are you really not following the conversation?
Obviously no. But you keep dodging the point here. And instead of comming up with an argument against my point, you seem to try to attack me personally.
That's true for any client that sends data to a server including your browser, email client or any other app. Colota doesn't operate a server. If you're concerned about server compromise, that's a server-side hardening question (disk encryption, access controls, etc.) that's outside the scope of a client app.
Colota is not a data aggregating service. It's a local-first app. By default, no data leaves your device. You choose if and where to send it. That's the opposite of aggregation. It's the user being in full control, which is exactly what self-hosted software is for.
It is. HTTPS is enforced for all public endpoints. HTTP is only allowed for private/RFC1918 addresses. Forcing TLS on 192.168.x.x would require every self-hoster to set up certificates for their LAN, which is a real barrier for the target audience. Colota already supports self-signed certificates if you install the CA on your device.
I didn't say that as an excuse. I explained why a client app that supports multiple independent backends can't enforce payload encryption. Each backend would need to implement the same decryption. That's a technical reality, not a lack of care about security.
Also again, a server is optional. It works offline and you can just export files with the data from the app.