{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreig3dz6ckeadhre2e3tcptwftfevset3oqxy6qfpxscurohhx4ayji",
    "uri": "at://did:plc:haakkg7y3xdghcdmprxeexso/app.bsky.feed.post/3mpgsqwkvxeh2"
  },
  "path": "/t/which-live-location-sharing-service-is-recommended/37533#post_20",
  "publishedAt": "2026-06-29T14:48:56.000Z",
  "site": "https://discuss.privacyguides.net",
  "textContent": "zlmr:\n\n> Well if you look at live location sharing flow in isolation you’ll see that it uses same principles, keys are ratcheting and every single location update is encrypted with new key. All other keys are rotating both periodically and whenever something in a group changes, old keys are always discarded and that system will heal itself if it is at any point compromised.\n\nIt wasn’t clear to me from your doc how key rotation interacts with location keys, so I might be missing something, but I think you are storing location keys on the server encrypted with a key derived from the MK or IK. If so, rotating keys does not provide any PCS if the MK or IK are compromised (obviously).\n\nThis is why a DH double ratchet uses Diffie-Hellman. If you just rotate epoch keys but they are stored on the server in a way that anyone with the root key can decrypt them, then of course you have no post-compromise security for the root key.\n\nThis is tangentially related to device- vs password-centric identities, but only tangentially: you could implement this with a password-centric identity where if Alice loses her session key she (automatically) re-establishes a (DH ratchet) session with Bob; the difference would be that Bob would be indicated that Alice–while still Alice, per her IK–has lost the device on which the session was previously established, which is probably a desirable property.\n\nzlmr:\n\n> FCM messages in Paralino do not contain any content related to the app, they are pings used to just wake a device.\n\nI meant the message from Alice to the server that causes the server to trigger the FCM push.\n\nThere does not seem to me to be any reason for place IDs to even exist, since Alice already must know which places Bob is interested in, and Bob already knows Alice’s locations. (Thus, Alice could just send an _empty_ ping to the server saying “notify Bob”.)\n\nzlmr:\n\n> “Design issues” is quite a stretch and can imply fundamental errors in the app and that I disagree with.\n\nPoor choice of words on my part. I meant these various themes.",
  "title": "Which live location sharing service is recommended?"
}