I found these but I am not sure which one is good for privacy.
Sorry, let me amend my comments on Paralino, reading a bit more:
- Don’t love the server-side storage of the identity key (though it’s encrypted via Argon2(password). Users often pick weak passwords! This is obviously designed to allow users to change devices without transferring keys locally between phones (or recover if they lose their phone) but it introduces a real weakness.
- I think there’s no post-compromise security for identity keys? They don’t seem to rotate. That seems to make the first bullet worse.
- It does not seem to hide group/user identities, so the server can see the social graph–just not message contents (i.e. location).
So I think the problems here are:
- Metadata (the social graph) leaks to the server. It’s fair to say that Grid and Where’s metadata hiding is sort of best effort–timing and IP addresses still can enable an adversary to figure out who is sharing with whom–but Paralino doesn’t have it at all.
- The user identity is tied to a static key derived from the password. If an adversary compromises the server and brute forces the identity key derivation, future location sharing is (I think) vulnerable, and I think this is true even if the user changes their password due to this.
Honestly, nobody is likely to be brute forcing your location sharing, so I think the above is just me being a nerd, but worth keeping in mind.
None of them, you want live location sharing and privacy in the same sentence, that is a fundamental contradiction.
None of them, you want live location sharing and privacy in the same sentence, that is a fundamental contradiction.
It seems like every time these types of location tracking apps are mentioned, there is always someone that says something like this. I guess I’ll be the one to explain it this time that wanting to share your location with someone you trust (such as a loved one), or to use it to locate your own personal device, doesn’t mean you want to share this location data with others that you don’t trust.
You’re confusing privacy and anonymity.
Privacy
Privacy is the assurance that your data is only seen by the parties you intend to view it. In the context of an instant messenger, for example, end-to-end encryption provides privacy by keeping your message visible only to yourself and the recipient.
By that definition, there is nothing inherently anti-privacy about location sharing apps. What matters more is how they’re implemented.
The Grid author uses AI very prominently, if that bothers you.
You are confusing how privacy and trust works in practice, user trusting third-party apps to honour their marketing claims, but when leaks happen, users have zero recourse, on top of the risk of live metadata exfiltration.
Hi, I am the dev behind Paralino, just to chime in on this encryption stuff 
.
- 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.
If 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. - 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.
Also 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.
Then 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.
But 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. - 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.
- 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.
If a government is chasing you then it is probably better that you don’t share your location non-stop at all.
If you are losing your mind because subject lines are not encrypted in ProtonMail, then you’ll probably find some drawbacks in Paralino as well.
If 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.
It is all about balance, control and getting to know the service - check the features, whitepaper and privacy policy before using it.
If I may ask, do you use VPN, email, chat apps, anything that has an account? Unless you are exclusive to Apple devices and services, all of those are third party btw, someone else wrote the code.
Even if you are self-hosting all of that, you are running third party code which can also has vulnerabilities.
What are the options for someone who wants to know location of their kids besides buying everyone an iPhone and using FindMy, which is the only first party service that is e2ee?
I share location data via a self-hosted Home Assistant setup. Of course this is not a service and you wouldn’t want to run that up just for location sharing, just noting it has the capability.
Sigh. Sorry–I’m new to this website, and I clearly cannot handle posting properly. Hopefully my cryptographic engineering is better than my using-this-website engineering. 
I had left an earlier reply (which I apparently failed to save or post) making a slightly broader comparison between these apps.
Let me first say, I appreciate what you are doing–I think it’s hugely valuable to have people make privacy *and* make a *business* out of privacy. So kudos to you for not only making Paralino, but commercializing it. (In full disclosure, I’m the dev behind https://where.af0.net/, which I noted in my accidentally-deleted post, and which you should feel free to critique and borrow from as you like. And in further disclosure, while I have a little bit of applied cryptography experience, I’m not a cryptographer.)
**
At a high level, I think any such evaluation should consider separately:
1. Protocol properties, including a) message contents (can an attacker or server see *where* you are?), b) metadata (can an attacker or server see *with whom you are sharing*, or infer something about your motion and activities?), and standard cryptographic properties (e.g. PFS, PCS).
2. Extra-protocol metadata leakage, e.g. map tiles leakage.
3. Developer/application trust, I suppose. (I saw people sort of criticizing you in a different thread for your app being closed source. I have mixed feelings on that: source is great, but without binary transparency, it’s somewhat *limited* proof.)
**
Evaluating the above, I think Grid is a pretty reasonable choice, with some caveats:
- It uses OLM, which is a pre-existing implementation of a well-understood protocol (the Signal double ratchet). For (1a), it should be trusted. However, I believe it does nothing to obfuscate message addressing, so on (1b) it fails–it leaks the social graph. Further, I have a mild complaint that Grid uses protomaps to load map tiles from their own server, with the *intent* of providing privacy–by excluding Google and Apple’s servers–but I think this deserves a caveat: they probably have far fewer users, and their map tile server is exclusively used for location sharing, so whereas your phone downloading tiles from Apple or Google could just be you opening Yelp to look for restaurants, in Grid’s case the custom map tile serving arguably makes it *easier* to track your location via (2).
In comparison, for my app, my own design choices were intended to minimize (1a) and (1b), i.e., I aim to provide message content secrecy *and*, as best as possible, social graph obfuscation, the latter by using “anonymous routing tokens”. That, however, is frankly of limited value if users are identifiable by their IP address, which is probably the case, so there’s no guarantee possible here. Unlike Grid, my app uses a custom implementation (also derived from the Signal protocol), and written by a sole dev using a lot of Claude on the weekend, so, you know, there could be bugs.
**
Now, regarding my comments about Paralino–and please note I only skimmed your design doc, so I might be missing things; correct me if so!
> 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.
That’s certainly a valid design choice; the question is really one of intended usage. My intended usage was to share my location with my friends and family, and it only makes sense to share the location of a single device at a time, so I felt device-based “identity”–with the simplification and privacy benefits it provides–was an optimal tradeoff. Indeed, if you want to support “find my lost device”, this is not a great option.
> 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.
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.)
- 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?)
- The identity key is static forever
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.)
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.
> 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.
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!).
I hope these comments are taken as helpful–like I intend–and not sniping. You’re doing great work here and, as I said at the outset, I also think it’s extremely important to have indie developers building private software.
PS: Oh, one other point on Paralino: the “place alerts” feature seems quite leaky, and I am afraid I don’t understand your design constraints here.
To my understanding, place alerts are implemented as a per-place unique hash shared among all group members. This means the server (and any MITM) can infer, for a group that contains Alice and Bob:
- if Alice and Bob are in the same place–because their “enter place” hash is the same fixed hash(place ID, “enter”)
- 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
What I don’t understand is, why use these hashes at all? You could just have a wire message that means “ping my friends” without the place hash?
Just Tuta left, but I am working through Docker Mailserver using rootless Podman Quadlets at the moment.
Well if you want a universal solution, the Snowden disclosures already highlighted that PRISM and other global surveillance programs are in effect, so if you ask your local government nicely and politely, everyone can simply indiscriminately spy on current and future generations to “secure” the future of children.
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.
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.
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.
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.
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.
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.
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.
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.
Next level setup you are pursuing, nice. But see, you still used Tuta and have probably at some point used some other services as well. Privacy is a personal journey and not a lot of folks can pull off what you are doing. And at different points in life, different people have different needs.
It can’t all be black and white, otherwise we wouldn’t even use internet.
Well yea ofc, that all stands, but you can’t expect that everyone goes to such extremes. You are always gonna be right when you say that best privacy is not using something at all.
But that is like answering to someone who asked which sunscreen to buy that in order to perfectly preserve their skin, they shouldn’t ever go outside. Which is a true statement, but it doesn’t really answer the question.
It does not matter if users use apps or not, global surveillance programs are going to operate without anyone’s consent regardless, so anyone looking to monitor their children without consent may as well use the same infrastructure their local government is using to be efficient and resourceful, since both parents and governments fundamentally agree on nonconsentual surveillance anyways.
you definitely have some nice privacy benefits by going device based approach.
Two thoughts on this:
- 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).
- If you really want device-less identities, have you thought about tying them to Passkeys instead of passwords, via PRF?
is everything in your project vibe-coded with Claude though or you are still managing something yourself?
Honestly, the majority is Claude. I was using this project as an opportunity to really see how much coding agents can help my productivity. In a green-field project where there’s a small core of hard design stuff (the e2ee protocol) and a very large chunk of fairly trivial stuff (the mobile application code), it does very well.
Quite frankly, I would not have been able to spare the time for a weekend project this ambitious without it.
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.
I think the key question is whether the person behind knows what they’re doing, as you say. A hand-coded app by someone who doesn’t know anything about applied cryptography, vs a vibe-coded app where the designer knows a bit more, I think the latter probably is safer!
Personally, I enjoy solving hard problems, via code or not. I will be honest: I hate writing mobile app code. It’s almost always filled with boilerplate and cruft–the ratio of “solving hard problems” to “lines of code” is far too low to be rewarding, which usually puts me off mobile app development.
Wouldn’t that then negate map tile leakage to some degree?
Yes, but my point was that if you’re using Grid’s protomaps endpoint, you’re leaking your range requests to them, and that they probably have less traffic (to hide in) than Google or Apple’s endpoints, and their endpoint is exclusively for people sharing location.
Now, I think the general community view of protomaps specifically is that “hey, it’s maps in a single file, so what is there to leak”, but that’s sort of incorrect–it uses HTTP Range to request the part of the map you are zoomed to (IIUC), so a malicious server or MiTM can still obviously know where you are browsing to.
So compromising identity key won’t compromise master key.
Yes, but what I meant was that in all probability both are compromised via the same mechanism (password compromise).
if your password is compromised then obviously your keys are compromised.
Right, this is what I mean about PCS. If a system has PCS, it can “heal” after transient key compromise. So with the Signal double ratchet, not only are old epoch keys discarded (PFS, i.e., someone who compromises you in the future cannot use the compromised keys to decrypt old captured traffic), but new keys are not derivable deterministically from a transient compromise, so the next epoch is once again secure.
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.
The nice thing about this scheme is that if Alice loses her phone and bootstraps a new one, Bob is alerted.
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.
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.
(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.)
probably would be better if those hashes would be per member as well
Yep!
I’m happy to talk through these design issues a bit more. Maybe drop me an email?
It 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.
And I do not plan to remove current email/password login, it is still gonna stay there as an option.
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. 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.
To 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.
And 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.
Technically 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.
What 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.
Your 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.
“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.
As 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.
I 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.
Do 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.
It 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).
This 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.
This 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.
I meant the message from Alice to the server that causes the server to trigger the FCM push.
There 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”.)
Poor choice of words on my part. I meant these various themes. 
To clarify it shortly (as in the architecture):
- None of the keys are derived from user’s MK or IK
- Base location key (i.e. sender key) is generated randomly on every device
- Those are exchanged between each member using their exchange public key pairs, more specifically with Authenticated encryption in libsodium
- From that base location key, new ephemeral key is derived which is used for encryption of actual live location data with Key derivation | Libsodium documentation
- Other members then can decrypt base location key with their private exchange keys, derive same ephemeral key from it and decrypt location data
- Key rotation fully recreates exchange key pairs, actual location key, group master key (encrypts group name and image, member names etc) as in here.
- Master key (also randomly generated, not derived from a password) is only used to encrypt currently active private exchange keys. And that encrypted blob is stored on the server (as in the chart). That is the only part that undermines PCS because you can eventually get to the location key with the master key. And this is also not required for actual location sharing process. Switching to local only private exchange keys is completely doable, although it would break current account based access.