{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifu7h4o5hv7uuvwy2a4xlmdhgekr3weov4wjadvjqh2sjsyeii2iq",
    "uri": "at://did:plc:haakkg7y3xdghcdmprxeexso/app.bsky.feed.post/3moi6227eoak2"
  },
  "path": "/t/nearly-family-location-sharing-without-the-data-harvesting/37803?page=2#post_25",
  "publishedAt": "2026-06-17T10:33:50.000Z",
  "site": "https://discuss.privacyguides.net",
  "textContent": "Hello All.\n\nEarlier in this thread I said full E2EE wasn’t feasible because the server needed plaintext location for doze wake-ups and geofencing. I reworked nudging service and geofencing rules are now pushed from child device.\n\nLocation (history), device name, phone number and smart-location (zone) names are now encrypted blobs the server can’t read. The keys are set during local-network pairing and never leave your devices. Pairing is automatic where possible; if that fails on some networks there’s QR pairing, and a manual code as last resort. After pairing you can compare a verification code on both devices to confirm there was no tampering in between.\n\nTo be straight about what I can still see: your account email and timezone offset (ex. UTC+02), plus the basic connection metadata any server receives (IPs, timestamps). What I can’t read is your actual location or history - it’s ciphertext to me. So a subpoena or a breach has no location data to hand over or steal. That was the whole point.\n\nStill solo and closed-source - that part hasn’t changed, and I won’t pretend it doesn’t mean the E2EE claim rests on trusting me until I can get the design independently looked at. Happy to walk through any part of how it works.\n\nThe E2EE build is live on Google Play. A direct APK from nearly.family is next.\n\n/Martin",
  "title": "Nearly – Family Location Sharing Without the Data Harvesting"
}