{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicckvejxshptvff7rhtfrbwb5i6q2e7agdezxkb7465o4fqqmz65i",
    "uri": "at://did:plc:haakkg7y3xdghcdmprxeexso/app.bsky.feed.post/3mp6mk64y47r2"
  },
  "path": "/t/which-live-location-sharing-service-is-recommended/37533#post_8",
  "publishedAt": "2026-06-26T08:32:06.000Z",
  "site": "https://discuss.privacyguides.net",
  "tags": [
    "know your threat model"
  ],
  "textContent": "Hi, I am the dev behind Paralino, just to chime in on this encryption stuff .\n\n  * If you take a look at Signal for example, you can consider its approach “device based” while Paralino is “account based”. That is intentional design choice because this type of service wouldn’t really make much sense otherwise. This way you can login on another device and locate your lost device for example, plus it is just way easier for average user to grasp.\nIf it would have been otherwise, it would be a pain for everyone to manage, transfer, backup etc., all their devices. Would also take literally forever to implement for a one person team (Signal has bunch of people working on it and it took them ages to handle backups reliably). That is why you have encrypted keys on the server.\n  * What exactly do you mean by identity key being tied to static key? It is not, identity keys are randomly generated on the device and not connected to a main key. Even main key is not connected to a key that is derived from a password. It is just encrypted with it.\nAlso identity keys are not generated on the server, they are randomly generated on device, encrypted with main key (which rotates) and then stored. And they are not used for encryption, just for initial signatures/authentication. If they are at any point compromised or tampered with, sharing would automatically stop on every device. Before every single location update device locally verifies all signatures for each member it shares its location with.\nThen there is another step, every group handles identity keys separately, so your actual identity key is unique per group not per user. That is why you have that Paralino.ID and technically you can have many of them, it is not just enabled in the user interface yet.\nBut regardless, having one and only identity key is not ideal, yes, but it is actually not something that can’t be improved, it is not blindly hardcoded in current design. It could easily be adjusted since support for it is already there. I do plan on enabling multiple ParalinoIDs soon, and bam → you can have many identities then.\n  * Social graph, yes, that is visible to the server to manage permissions and handle different plan management features. But this is a privacy first service, that data is not shared with anyone nor is it used for anything else except technical functionality of the app. Also, server still doesn’t know who exactly you are or who your members are - it is just random identifiers in the end.\n  * And the most important factor of it all → know your threat model. Paralino’s main audience is families and friends who want something that works reliably, has the features that other mainstream location sharing services do, but protects their privacy and gives them peace of mind that no-one else is able to see where they are.\nIf a government is chasing you then it is probably better that you don’t share your location non-stop at all.\nIf you are losing your mind because subject lines are not encrypted in ProtonMail, then you’ll probably find some drawbacks in Paralino as well.\nIf you want to escape big tech or you ever used any other location sharing app, then you are gonna love Paralino - you know where your kid is and that’s where it ends, not a single other person or a random computer in some random country knows that.\nIt is all about balance, control and getting to know the service - check the features, whitepaper and privacy policy before using it.\n\n",
  "title": "Which live location sharing service is recommended?"
}