Which live location sharing service is recommended?

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.