{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicxe5zkeejxbmv5lsma3a65ui4kzbriqb76kmn3nrvgro5s5zi57e",
    "uri": "at://did:plc:haakkg7y3xdghcdmprxeexso/app.bsky.feed.post/3mllqo4pe6bj2"
  },
  "path": "/t/nearly-family-location-sharing-without-the-data-harvesting/37803#post_11",
  "publishedAt": "2026-05-11T16:01:05.000Z",
  "site": "https://discuss.privacyguides.net",
  "textContent": "1 & 2. Transport is encrypted via HTTPS/TLS. Device pairing happens over the local network and is end-to-end encrypted. I have experience implementing high-grade data protection in other projects - but here the server fundamentally needs to know the location to do its job: nudging devices Android might have put into doze mode and evaluating geofence rules server-side. Full E2EE would break that. To be transparent - as the server operator I can query the database, so location data is visible to me at the infrastructure level. That’s a real architectural constraint, not a convenience trade-off.\n\n3. Fair request - a direct APK download is something I can add. It’s not complicated, I just used the Play Store as it automatically selects .aab per users device architecture which also reduces install/update size.\n\n4. I can’t guarantee zero vulnerabilities in dependencies - nobody can honestly. I use latest stable sdk/libraries and keep an eye if any gets reported.\n\n5. Legitimate concern and I won’t argue against it. Closed source requires trust by definition. I can only be transparent about how it works when asked, which I’m happy to do.",
  "title": "Nearly – Family Location Sharing Without the Data Harvesting"
}