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. There is also an option to just not record locations in a geofence but then the GPS stays on and will still drain some battery.
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.
Glad it’s working well for you!
All location data is stored locally on device in a (unecrypted) SQLite DB. Auth headers (Bearer tokens, Basic auth) are stored using Android’s EncryptedSharedPreferences. HTTPS is enforced for all public endpoints. HTTP is only allowed for private/local network addresses (192.168.x.x, etc.) for self-hosted setups. For a app where the user controls both endpoints, I think that’s a reasonable tradeoff (https://colota.app/privacy-policy/). Probably makes sense to also mention that in a separate page in the docs for easier overview. Thank you for the question.
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.