It’s using react native so it’s definitely possible. Currently it’s not planned, but it’s also not off the table forever (https://colota.app/docs/faq#is-there-an-ios-version)

Yes, another user also already requested this (“Seeing the same SSIDs (eg in a cinema)”). Detecting reliable if you left an area without GPS is never 100% fool proof (e.g. airplane mode turned on or maybe the motion sensor is not even available) so I guess it makes sense to combine different sensors. Seeing same SSID and bluetooth is definitely on the test it out list.

If the target server is compromised or taken by LEA the data is gone.

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.

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.

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.

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. 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.

It is no excuse that other services do not follow these state of the art protection measures.

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.

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!

• “filtering trips near a point”: Not yet available, but planned as part of location history search/filter features. It will be also using a configurable Nominatim instance for reverse geocoding points to addresses.
• Import: Doesn’t exist yet. But is also on the roadmap (including export/import for geofences).
• Deletion of points/trips: Currently you can delete older than X days or delete all. No date range picker or bulk delete from the history timeline yet but that will be neccessary. There will be options to delete trips (which may be just GPS jitter) and (bulk) delete points.

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.