{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifbeoxvqc2climiuxmgfnq5grvvkhh6tbwualzcf5upmmfxiqjanm",
    "uri": "at://did:plc:haakkg7y3xdghcdmprxeexso/app.bsky.feed.post/3mpgm223jtvy2"
  },
  "path": "/t/which-live-location-sharing-service-is-recommended/37533#post_19",
  "publishedAt": "2026-06-29T12:51:07.000Z",
  "site": "https://discuss.privacyguides.net",
  "tags": [
    "PRF",
    "thought"
  ],
  "textContent": "dm:\n\n> Two thoughts on this:\n>\n>   1. Are you sure you want a username/password-centric identity? I think the only thing this really gets you is allowing the user to find their own lost device by bootstrapping a wholly new device via the password–which strikes me as a potentially unimportant use case. (Multidevice users can still do “find my” with a device-centric scheme, depending on some design choices.) **I think a good security property is that if Alice changes devices, Bob gets a notification and has to re-opt into sharing** , which can be done various ways (e.g. an identity key + a device key).\n>   2. If you really want device-less identities, have you thought about tying them to Passkeys instead of passwords, via PRF?\n>\n\n\nIt was already requested a few times from others to have support for some sort of multiple device option without email/password (Passkeys basically) and it is already on the roadmap. But it is not one line of code, it takes lots of time to build and fit into the current feature set, so in the end it is a question for Eisenhower matrix. I don’t have exact timeline for this.\n\nAnd I do not plan to remove current email/password login, it is still gonna stay there as an option.\n\ndm:\n\n> You lose this property by tying key rotation to the IK/MK. If you used a DH ratchet, as Signal (and Where) do, you’d get PCS on epoch rotations _even if the password were compromised_ , though this is only helpful if you alert users on new session establishment instead of blindly trusting the IK/MK.\n\nWell 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. Different keys are also used for different things in the app so MK/IK keys are just one set. Key that encrypts the group name is not the same key that encrypts location data.\nTo go back to Passkeys, as that is already planned I could add local only keys support and everything else can mostly work as it does already.\n\nAnd as said already a few times, it should be quite obvious that this is an account based system. It is not as local as Signal so expectations should be pretty clear. Being only local allows you to have keys without one password protecting them so it is obviously gonna be more robust since it is not tied to that one key. You don’t need to persuade me that it is better, I agree that it is ofc.\n\ndm:\n\n> It seems to me you could achieve this without the hash/place IDs by just having Alice send the server a message when she enters a location Bob is subscribed to, and have the server do a push notification. That way, the server knows Alice entered a geofence, but not _which_ geofence.\n\nTechnically it could have been done in bunch of different ways, and the way it works now is not wrong but it can also be improved ofc. What I wanted at first is to have similar approach for all others events in the app, but it just wasn’t worth the time effort at that moment. I’ll switch to a different system anyway because I plan to add few other features that all require some sort of events and notifications. So having them use a shared event flow is easier to maintain and it obscures various event types even more so server won’t even know if event is for geofence or for something else.\n\ndm:\n\n> (I thought about using FCM to wake devices to make background pings more reliable, but the privacy tradeoffs we are talking about seem to me somewhat unavoidable–even if the messages are zero content (unlike yours), they still leak metadata in an undesirable way.)\n\nWhat do you mean with “unlike yours”? FCM messages in Paralino do not contain any content related to the app, they are pings used to just wake a device. And you are not tied to FCM with Paralino, that is just on Google Play version. De-googled version uses built in direct connection to the server without other parties and there is even UnifiedPush which is also just dummy pings.\n\nYour average family is probably running on Samsung’s devices, so not using FCM on Google Play means they are gonna pick an ad-infested app that works but it tracks and sells their data back and forth. They don’t know nor care what FCM is but they still deserve some privacy without compromising on features.\n\ndm:\n\n> I’m happy to talk through these design issues a bit more. Maybe drop me an email?\n\n“Design issues” is quite a stretch and can imply fundamental errors in the app and that I disagree with. As said many times before it is an intentional approach with pretty much clear balance between full anonymity/privacy vs features/convenience vs time needed to develop all that. If something is working the way it is, I am very much aware of its limitations, intended purpose and feature set, and most importantly user base that it is built for.\nAs you can already see, just being a location sharing app is a “design issue” in itself. So in that regard we both failed before we even started.\n\nI also don’t want to spam the thread further since it is not supposed to be about Paralino and I already feel like I am both talking too much about it and repeating myself.\nDo reach out at contact@paralino.com if you have any more questions, I am happy to continue the discussion and will do my best to answer anything else you might throw at me.",
  "title": "Which live location sharing service is recommended?"
}