you could only expose a webhook which is deployed public and then forward the locations from the webhook to the dawarich instance via wireguard or just use a vpn also on the client

🙋

I use it to track travel times for work and sometimes create maps of trips. Also I personally just like to see oh I was there a few days/weeks/years ago which brings up memories

Owntracks can do that but it has a limit of how much locations can be stored locally. I think it was 100k, so depending on your tracking interval during the month you may hit the limit. Also it still tries to sync every few minutes even though the server is down. Colota (https://github.com/dietrichmax/colota) supports the same without a limit and you can use it in a offline mode and then export e.g. a geojson and import it into Dawarich or you set it to only sync it on a imaginary SSID like "abc " and then change it to the correct one when you actually want to sync. So it never even tries to sync until you really want it to. Disclosure: I'm the dev of Colota.

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.

FusedLocationProvider (GMS version) is generally better for most users. It combines GPS, WiFi, cell tower and sensor data for faster GPS fixes and better battery efficiency. The FOSS version uses raw LocationManager with GPS as primary and network as fallback. It works but GPS fixes can be slower, especially indoors. But if avoiding (sandboxed) Play Services is a priority, the FOSS version works fine too.

No I understood the server is self-hosted…?

Colota is client-only. There is no Colota server software. When you add a server endpoint in the settings, you're pointing it at your own existing server (Dawarich, Home Assistant, Traccar or any HTTP endpoint). Colota doesn't provide or require any server component. It just sends data where you tell it to.

I see that but this should be an automatic backup process. Plus there’s no way I can see to IMPORT that data somewhere else. When I use an app like Fitotrack, it automatically makes a backup file periodically and then is automatically backed up to my server with Nextcloud or Syncthing. I don’t need a dedicated server for it.

Colota actually has automatic file export (Settings > Export Data > Auto-Export) that periodically exports to a directory on your device. From there Syncthing/Nextcloud can pick it up. Import is not yet available but is planned. There is no dedicated server needed and also not offered to setup. However you can create a webhook on your own server for the app if you want to. See e.g. https://colota.app/docs/integrations/custom-backend.

How can it do that when it didn’t ask me for an SSID? And what’s the point of the geofence if it doesn’t even use it anyway? I am cornfuse.

WiFi pause doesn't use a specific SSID. It detects any unmetered network (WiFi/Ethernet) while you're inside a geofence zone. The geofence defines where the pause should happen, the WiFi connection confirms you're settled there and is used to detect when you leave it. Without the geofence, any WiFi connection would pause tracking everywhere.

How is motion recognized without GPS?

Motion detection uses the device's hardware motion sensor (if available). It's a low-power sensor that fires when physical movement is detected.

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.

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.