Which live location sharing service is recommended?

Thanks for a great response, I really appreciate all the thought process and time taken. I enjoyed going through it. I like conversations like this so I can’t ever take anything the wrong way when we are having a friendly chat driven by curiosity . Thanks for taking the time to write back. Also kudos for the project, I quickly skimmed through the wiki, you have a lot of stuff there and are onto something good. Architecture wise it looks very interesting, and yea you definitely have some nice privacy benefits by going device based approach. You can really follow and even tighten Signal’s protocol in that case. And great that you’ve already open-sourced it, I am dragging this too long but I am planning on open-sourcing clients next week. I get that for a lots of people that is absolute must and some have all-or-nothing approach regarding open-source, so it’s understandable that there are complaints. But I was always just more focused on working on the app itself and somehow I just keep postponing making a simple Readme file and toggling project visibility. Classic just-one-more-feature trap . But just wondering, is everything in your project vibe-coded with Claude though or you are still managing something yourself? I saw that there is a Grid app as well, it looks nice but it seems like it’s mostly AI doing all the work recently therefore I haven’t even looked further into it nor what it does. I not really sure yet what to think of this full-AI-mode and if it is a good or bad approach. As long as the person behind it knows what they’re doing, it is probably of a great help and project would not even be live otherwise. But since also everyone can just write prompts I am always vary when there is too much Claude in the mix. Ending up with a massive amounts of random code in a short time doesn’t seem stable nor sustainable. I personally love coding way too much and just using AI would take away from the joy of working on it. And I wouldn’t trust it to fully write something for a sensitive privacy-focused project. Also regarding Grid’s map tiles approach, I do think it is a pretty cool solution because you can self-host the tiles right? Wouldn’t that then negate map tile leakage to some degree? Which then turns that approach in a positive basically. Either way, I do love that there are more and more Indies focusing on privacy-first project, this can only be good for everyone since there are lots of services that need alternatives. dm: > I was sort of mixing up the identity key and master key here. (In practice, I assume an attacker who compromises one can probably compromise the other, since they both ultimately are encrypted with the Argon2-stretched user password.) Identity keys are encrypted with a master key, which is in turn encrypted with derived key from user’s password. So compromising identity key won’t compromise master key. If a master key is compromised then obviously it is a different story, but that is ofc expected. dm: > - The master key is static except for password changes (and those don’t take effect *immediately*, as far as I can tell–e.g., prekeys issued from the *old* master key remain valid until they run out, right?) Prekeys are tied to Paralino.ID, not to a master key. In app settings you can even toggled on/off your Id which will create new prekeys. So basically you can “rotate” those separately. dm: > So if either is compromised, an attacker can do various things–MITM key rotation (thus intercepting an existing session), issue new pre keys, decrypt existing pre keys. So there’s no PCS if the user’s password is compromised, I think. (It’s also not entirely clear to me what rotating the master key on password change gets you due to the static identity key.) Well yes, if your password is compromised then obviously your keys are compromised. That is also how cloud based password manager works for example. As said previously, this is account based service, so your password protects your keys. No encryption in the world will protect you if someone for example grabs your password vault and your password is 1234. And rotating master key when password changes is just good practice. All new data is then encrypted with new keys. If someone compromises your account, they won’t be able to get and reuse the same key for accessing newly encrypted data after you change your password, even if they have old keys. Or if you maybe realised you had a weak password, you change it to something better and will get new keys which are then protected with better password. dm: > A related problem I did not mention (because you already called it out!) is that the Paralino ID is itself too short to provide meaningful identity security. This is fixable, though. And yea, it is short, but intentionally for user experience. Would be super easy to make it longer in the app but for now I am keeping it like this. I still feel like group invite would be a better and easier approach for users, but well, I didn’t get there yet. So I might even phase out ParalinoIDs to some degree in the future in favour of expiring group invites. Regarding place alerts, since all logic happens on device you can’t really use server to determine any enter/exit logic. At first I had simple enter/exit pings, but I switched to hashes just to minimise available data and to possible extend this for some event base features in the future. In the end those work like an id for an event. Not sure why I called them hashes though , it is a confusing name definitely. They serve more like a noise to obscure actual events. I also need them because of specific feature, in the app you can adjust settings for each member if you want to receive notification when they enter or exit a certain place. That setting is then saved server side so server can either send or skip notifying you about specific event. But what is saved is just that hash/id, not a plain text enter/exit flag. dm: > * if Alice and Bob are in the same place–because their “enter place” hash is the same fixed hash(place ID, “enter”) > Now when I am looking at your scenario, probably would be better if those hashes would be per member as well, which would protect it better in case of Alice and Bob being in a same place. Good catch and thanks for the hint, I’ll look into it more. dm: > * what the “exit” code is for a place–if, over a period of traffic analysis, hashX is followed only by hashY, then hashY is the “exit” code for the same place as hashX is the “enter” code > And hashX can be followed by hashX again, devices are noisy and can send multiple equal events. Also if you get offline or are in the area with a bad signal, event logic can discard some events in certain timeframe so you end up with enter first and then enter again after some time. If you start sharing location while in a place like home, you won’t get enter home event. First one will be for exit. And if you start sharing outside of a place, first event would be enter, otherwise you would receive exit events for all places you have. So it is not really trivial to say enter is hashX and exit is hashY. But anyway the most important thing is that the server still doesn’t know where is you place or where you are, this event hashing is just for a tiny bit extra obscurity. dm: > Totally agreed, and just to be clear, I’m not saying people should avoid using your app. But it’s hard to design a realtime e2ee messaging protocol from scratch–which is why I stole almost all relevant parts of my design from Signal!–and in doing so, it’s easy to introduce *theoretical* risks and design compromises (many of which, to your credit, you were already aware of!). Yea exactly, more than half of the effort that takes to build something like this goes into e2ee stuff. But luckily as you said Signal and co are well documented so it is easy to learn from it. And risk is not something you can ever avoid, it is something you need to manage. There are always gonna be tradeoffs between user experience and how far you can push your protocols. Because if in the end some software gets in your way, you are more like to not even use it regardless of how much privacy it gives you.