Fair point and good finds - looks like we were all working on this at the same time independently.
As next step I could focus more on E2EE and move some of the logic to make it work. Are there any other improvements you’d suggest?
4 Likes
E2EE & encryption-at-rest are really good starting points. For data as sensitive as the realtime location of my child, a ‘private’ solution should imply a zero-trust threat model. Accessing any location data should require an encryption key that I alone possess
Implementing those encryption techniques will make my location data a random pile of encrypted garbage, both in-transit between server & client, and while stored in Nearly’s database. This is similar to Proton’s approach for many of their services
- Zero knowledge: Nearly cannot read my data at any point. Users need not be concerned that Nearly is, or can be made to become, a bad actor
- Data breach: criminals have hacked Nearly & stolen my data? Who cares, the database is encrypted, these hackers can’t read it
- Subpoena: Nearly has a customer under a totalitarian regime? Worry not, Nearly cannot be made to compromise user location, database is unreadable
Another low-hanging fruit: provide a build to FDroid for distribution. Using Play Store is reasonable for broad distribution, but you’ll need a degoogled version for the privacy-minded community you are targeting
Further down the line: as it stands, a lot of Nearly’s privacy is based on promises:
I have no doubt that Nearly means well on these claims. But big tech companies have made similar claims, and broken them for profit. A promise does not protect privacy - verification & accountability is needed. Through either open-sourcification or a third-party audit, Nearly will need to allow independent parties to verify its software is secure, and its data practices are above-board
For what it’s worth: there’s no issue with your subscription model. People gotta eat, many folks in here will happily pay for a valuable service. You will eventually be probed to provide anonymous payment methods, whether via Monero or ProxyStore gift cards
6 Likes
Also: don’t be discouraged by the feedback in this thread.
It’s important to outline capabilities, threat models, risks, and expectations for ‘private software’. For some, it’s a matter of grave importance.
But anyone making an effort to improve the privacy landscape is offering a net benefit to society, the effort is indeed appreciated. I sincerely hope to watch Nearly grow into a tool we can add to PG recommendations
3 Likes
Thank you - genuinely. This is exactly the kind of feedback that makes building in public worthwhile. You and others in this thread have pushed me to think through things I had rationalized away, and that’s valuable regardless of where Nearly ends up.
E2EE and zero-knowledge - the architecture conversation this thread sparked has me convinced it’s more achievable than I initially thought, and it’s now a serious roadmap.
Open source and audits - fair point, promises aren’t verification. I can’t commit to a timeline on either right now, but I hear it.
I actually have a custom APK delivery and self-update system already built for other clients, so a de-Googled build is something I can realistically offer. I’m already verified developer but lets see the friction in the next couple of months on how exactly will Google enforce this.
Thanks again - this thread has been more useful than most.
6 Likes
Hello All.
Earlier in this thread I said full E2EE wasn’t feasible because the server needed plaintext location for doze wake-ups and geofencing. I reworked nudging service and geofencing rules are now pushed from child device.
Location (history), device name, phone number and smart-location (zone) names are now encrypted blobs the server can’t read. The keys are set during local-network pairing and never leave your devices. Pairing is automatic where possible; if that fails on some networks there’s QR pairing, and a manual code as last resort. After pairing you can compare a verification code on both devices to confirm there was no tampering in between.
To be straight about what I can still see: your account email and timezone offset (ex. UTC+02), plus the basic connection metadata any server receives (IPs, timestamps). What I can’t read is your actual location or history - it’s ciphertext to me. So a subpoena or a breach has no location data to hand over or steal. That was the whole point.
Still solo and closed-source - that part hasn’t changed, and I won’t pretend it doesn’t mean the E2EE claim rests on trusting me until I can get the design independently looked at. Happy to walk through any part of how it works.
The E2EE build is live on Google Play. A direct APK from nearly.family is next.
/Martin
5 Likes
Is your long term strategy monetization? And what’s the chance you’d consider a buyout vs keep yourself as the owner?
I’m happy to pay for such services, but I’m also not as interested to have it rug pulled if bought out.
1 Like
Thank you for sharing the end-to-end encrypted alternatives. This is the first time I’ve heard about Grid and Paralino, just wonder why these are not in the recommended tools of Privacy Guides? I just checked and noticed there is no Location Sharing section in the guide.
I suppose because they are not brought forward by the community and not tested (yet).
This comment with llmisms combined with the website design is giving me the sense that AI is being used heavily in this project. This combined with lack of source code is heavily pushing me away.
I’m not trying to witch hunt AI. And it might be AI edited and not generated or maybe there’s no AI at all, one can’t ever be sure. I don’t mind devs using AI when I trust them and the code is open source and audited, but this is just my personal reaction.
Also why is phone number being used?
Seems like there’s a ton of these services popping up so I’m happy about the competition and looking forward to who comes out on top.
Nearly (gh) open source not planned, e2ee, play store only, android only. Actively developed.
Paralino (gh) open source client planned, e2ee. Play store only, iOS support. Actively developed.
Grid (gh) - open source, AGPL clients, unsure about server. E2ee, degoogled, grapheneos support. Play store, gh, iOS. ~500 stars on github. 1.9/5 stars on play store. Jan 2026 last play store update
Zood (gh) - open source client, e2ee. AGPL Unsure if server is open. Izzyondroid, gh, fdroid play store, iOS. Android App ~160 stars. 2025 most recent update to android app.
Owntracks (gh) open source client and server, no e2ee. Over 1700 stars. Play store, GH, F-Droid, iOS.
Lmk if there’s something missing from my comparison I just did a brief look.
4 Likes
Very cool idea.
Would this feasible as an alternative to Life360? As I understand, that app isn’t specifically for monitoring parent/child - it can be used to monitor your spouse, other family members, etc. My wife and I have talked about using a service akin to Life360 so we can see where each other are. We usually text each other updates throughout the day but if something happened to one us the other wouldn’t know their precise location, only where they were going. This app seems to solve that issue in a privacy conscious way. Can both the “parents” on an app see each other or can they only see the child?
If there are true E2EE (A)GPL clients offering the same thing, then I would largely refuse to use this service until it catches up to the others.
As the saying goes, E2EE can me enancryption between client and server, so I think we need a big bold preface saying transport encryption is a bare bones expectations, and E2EE between client to client where a server cannot read privacy data is a requirement for a privacy preserving solution. When we say E2EE, we colloquially mean client to client encryption.
It’s one thing to not encrypt say an email, but the whole point is to encrypt location data. It’s an architecture tradeoff if you aren’t thread modeling as to what is required, and that is to distrust the server.
1 Like
Awesome. Thanks for sharing, and nice work. The website is clean looking as well. Any plans for ios? I have some family that want me to have their location, however im android and theyre iphone. For me and mine i used Zood which was simple and worked well for us, but i’ll keep yours in mind for kiddos.
1 Like
Thanks everyone, lot to catch up on.
@unseen / @ph00lt0 - I’d welcome Nearly going through that testing once it’s open to independent review.
@Expert4870
AI: I use it, but only for debugging and boilerplate, plus website touchups (probably the “llmism” you spotted). The architecture, patterns and services are all mine. Some parts are even borrowed from past projects, long before LLMs took the stage.
Phone number is optional contact identifier for quick contact when getting an SOS from the child. Encrypted blob since the E2EE update.
Comparison table: one fix to the Nearly row. Full client-to-client E2EE shipped in June, and a direct APK is next.
@The_Centurion - Fits the Life360 use case. Worth noting: parents only see the child, not each other. There’s no parent-to-parent visibility right now which is nice idea.
@overdrawn98901 - Strategy is what’s already live: a subscription covering infrastructure. No company or investors to buy out, just me, and I won’t sell.
To flag what’s easy to miss in a long thread: as of post 25, Nearly is client-to-client E2EE, not just TLS. Geofencing runs on the child device, and location, history, zone names, device and phone number are all encrypted blobs the server can’t read. Keys are exchanged during local pairing, never leave your devices, with a verification code against tampering. Still closed-source and solo, so the claim rests on trusting me until the design gets independent review.
@Footprint - Thanks. Android only for now, no iOS timeline I can commit to. Glad Zood works for you in the meantime.
/Martin
1 Like
I think this is what’s confusing me.
Well it was like that but since last update that logic changed in order E2EE to work.
1 Like
Without making this open-source. How can we really trust the E2EE is actually really in place and there’s nothing that you can see?
If I can’t see the code how do I know you are indeed encrypting the info? Or you aren’t encrypting but saving a copy somewhere? I might miss something in the thread where you mention this. But is the project based on faith on you/admins?
I really like the idea and would happily pay for this. But how can I trust the data is really private? Specially important since we’re tracking kid’s location here which is ultra-sensitive.
3 Likes