Show HN: End-to-end encrypted location sharing service like Google Latitude
zood.xyz
zood.xyz
I’d like to find a way to charge for this service so I can spend more time on it, and building other privacy preserving services, but I’m not sure of some things:
* Is this a service you would use?
* Would you pay for it?
* Would you or your company sponsor it?
Happy to answer any questions you may have. Any feedback is appreciated.P.S. I'm sure you may be wondering "where is the iOS app?". It's coming. Real soon. Now'ish. Later. It's currently undergoing a UI overhaul, and because all of the people I share with are Android users, it hasn't been as high of a priority.
Interesting. Been thinking about something like this. You mentioned other privacy preserving services; which products do you think are most in need of privacy preserving alternatives?
Re: other services.
I'd like to implement something akin to Google Photos but where all your images are encrypted before going up to the cloud for storage. All the fun face recognition features and indexing would have to happen on your phone, but phones are plenty powerful enough these days to do that while you're sleeping and your phone is plugged in and charging.
I'd like to implement a simplified personal assistant like Google Now, that doesn't depend on sending your personal data into the cloud. Again, phones are so powerful and they already know so much about you based on local context, that I think there's a big opportunity for making a "good enough" assistant that doesn't compromise your privacy.
More mundane, but I think still very useful, is being able to store your contacts in the cloud, but making sure they're encrypted with a local key you control, so the storage provider (e.g. Zood) can't see your contact list.
An actually trusthworthy VPN provider. Mozilla entered this space a couple months ago, and I think it's great that there is at least one trusthworthy VPN brand now. It's a very confusing market for people to navigate, but I'd like to earn the trust of people so a Zood VPN product would become a viable service.
Along the theme of helping people extricate themselves from the advertising and surveillance economy, a service that helps people remove themselves from these junk snail mail lists. You can do it on your own right now, but it can be overwhelming.
I have lots of other little ideas, but they aren't quite ready for discussing. :-)
Checkout "Stingle Photos" [1], very similar stack to what you described.
[1]: https://stingle.org/
One thing I've actually not seen is E2E contacts & calendars. Everything seems to be based on CalDAV & CardDAV which I think forces you to sync them with a server in plaintext. Email is mostly a lost cause, the closest you could approach it is something like protonmail AFAIK.
Also as far as 'good' VPN providers, I think PIA & Mulvad have fairly good reps. Mulvad even lets you pay in mailed in cash.
Sorry about that. I certainly get the appeal of "one app to rule then all," but as an indy solo dev, I have to focus on building features that give my users the best bang from my limited time.
File sync is surprisingly hard to do cross-platform--most apps have pretty abysmal app store ratings, including the built-in ones from NAS manufacturers.
I personally use Resilio Sync as a one-trick-pony that just copies my smartphone photos to my NAS. There are several other apps to that do this, as well: https://photostructure.com/faq/how-do-i-safely-store-files/#...
PhotoStructure's sync process then automatically finds and imports new files into my library.
A homepage bookmark icon on my phone that links to my personal PhotoStructure library works well.
Totally agree. I think the natural progression of things to replace would be contacts and then calendaring. For the life of me, I can't figure out what should/how to replace email. Or simply make it more secure for the masses.
Disclaimer: I created it.
Either way, awesome idea and love to see what you’re doing.
My current understanding is that location data is not leaked to Google or Apple by just enabling location services (I'm always happy to be proven wrong :-) ).
In the case of Google/Android, they make it very easy to unknowingly opt-in to sharing your data with them, but it's not too hard to double check that and disable+delete the data it if was on [1].
I know there has been much news about Google providing police with a list of devices near the time and location of a crime, and I believe that data is coming from the Location History feature of Google accounts. But that's something that can be turned off.
Apple more explicitly requests the data via app permissions on your iPhone, so it basically comes down to what Apple apps to which you've given location permission [3].
[1] https://support.google.com/accounts/answer/3467281 [2] https://support.google.com/accounts/answer/3118687 [3] https://support.apple.com/en-us/HT203033
Nowadays I just keep the GPS off unless I need to use Maps, hopefully that does something.
https://support.google.com/accounts/answer/3467281?hl=en#loc...
This is not possible on iOS. If your app gets a user's location, Apple will get it also.
https://support.apple.com/en-us/HT207056
"To use features such as these, you must enable Location Services on your iPhone and give your permission to each app or website before it can use your location data."
"If Location Services is on, your iPhone will periodically send the geo-tagged locations of nearby Wi-Fi hotspots and cell towers (where supported by a device) in an anonymous and encrypted form to Apple"
"By enabling Location Services for your devices, you agree and consent to the transmission, collection, maintenance, processing, and use of your location data and location search queries by Apple and its partners and licensees to provide and improve location-based and road traffic-based products and services."
I would pay that much for the cloud offering if you had a contractual/legal obligation NEVER to sell my data EVER, or to sell the service to any company without wiping ALL of my data first.
Zood Location only sends your location to users that you have explicitly added, and your location data is end-to-end encrypted before leaving your phone meaning that the data can only be decrypted by the person your sharing it with (i.e. your wife or your son.
As for your personal data, Zood doesn't get any of it because of the end-to-end encryption. All the server [1] does is accept blobs of effectively random bytes (encrypted) from users to deliver to other users.
Even if I wanted to sell user data, there wouldn't be anything to sell. Everything is encrypted before it leaves your phone. It's just like Signal in that regard.
Does zood know who is sharing with whom? Is the data usage to username logged?
Is the amount of data sent to zood increase as a function of 1. How many people you are sharing your location with 2. If you are traveling quickly 3. If you are on battery saver or not?
> I would like more information on what information exactly zood receives and stores.
When you sign up, the Zood Location server receives
* the username you picked
* (optionally, if you provided it) your email address
The server also stores a backup of various pieces of data for you, but this data is encrypted on your phone before being backed up to the server. It's exactly like how a password manager backs up your passwords to the cloud so you can access them from any machine. THIS DATA IS ALL ENCRYPTED ON YOUR PHONE with a key DERIVED FROM YOUR PASSWORD before the blobs are sent to the server.
The encrypted data includes:
* your symmetric key
* your asymmetric key
* your password salt
* the algorithm used for your password derived key (currently, argon2id)
* your friends list and their public keys (for TOFU reasons)
Again, all that data is encrypted in the app on your phone before it ever leaves your device. This is no different than using a password manager.
> Does zood know who is sharing with whom?
The most information that the server can ever see is that some user sent some communication to a particular user. The contents of the message are unknown. Location sharing actually happens through "drop boxes" to make it more difficult for the server to see when and how often users send communications. When a friendship is established, the friends agree upon drop box addresses to use for each other, and they simply place encrypted data in the drop box for the other user to check whenever it wants.
In theory, I could perform metadata analysis to try to statistically determine friendships, but I still wouldn't know anybody's location. The server code is available, and not terribly complicated so it's easy to verify that no analysis is happening there [1].
> Is the data usage to username logged?
For debugging purposes, I can have the server log to stdout when a user makes a REST call to drop an encrypted blob on the server, or when a REST call is made to send an encrypted blob to another user, but that's off in production. It was there to help me build the thing.
In general, thwarting metadata analysis by the person running the service is tough. I look to what the Signal messenger folks are doing in this space to improve things.
> Is the amount of data sent to zood increase as a function of 1. How many people you are sharing your location with
If you have more friends, your phone will send more encrypted blobs to different drop boxes on the server. The reason is that though you only physically exist in one point of space at a time, because communication with each friend is end-to-end encrypted, your phone will encrypt the location info payload for each friend with their own public key. So if you have 5 friends, every time your location changes, your phone will encrypt the payload 5 different times and place it in five different drop boxes on the server.
> 2. If you are traveling quickly
That's based on your phone's operating system and version. Google and Apple are always tweaking how often location updates are reported to apps. But if a location update comes in, Zood will encrypt it and upload it.
> 3. If you are on battery saver or not?
I don't really use battery saver, but I think location services is disabled when your phone is in that state, so Zood wouldn't get any location updates at all. I could be wrong about that.
You might be surprised. You wouldn't need to sell user data, but there certainly is something of value from the cloud offering you (and your users!) should be aware of.
The logs of location sharing uploads and queries contain two pieces of information that together would allow for certain types of analytics:
* Approximate location even from partially redacted IPs (via geoip lookup)
* Timestamp of action
The value of that information is not in individual users or their data. It's in their aggregate behaviour in locations over time. Want to know where privacy-aware users are more likely to be found? Or how about where the trend of privacy awareness is increasing or decreasing?The people who are actively aware of their privacy are more willing to pay for good services. That's a marketing cohort all by itself.
NOTE: I'm writing this with my DPO hat on, because even if the impact assessment for using this kind of service would be pretty simple, it would not be a no-op.
Yes, metadata can always be analyzed and exploited. I just hope that by open sourcing the server and the client, that I can earn some trust from people to know that I'm not doing anything like that. This is not a problem unique to this server, it's a problem of all servers in the world. And if a user is particularly concerned about exposing their IP to the server, they can always access it via a VPN or proxy server.
Zood Location can't overcome every single threat out there, but it can significantly reduce the number of threats you have to deal with.
It's just that with something that advertises E2E encryption, the expectations are high. Unavoidably so. Doesn't help that various snake-oil salesmen have tried to hijack the term too, because of its implied strength. So being upfront about the threat model and in particular what your service can not protect against is important.
It just happens that in this particular case, the not-in-threat-model-scope is also a thing of interesting value. Perhaps even more so if your service gets adopted by civil rights or other organising movements.
(I help maintain the OT Android app)
That said and if I read you correctly, the backend must be some sort of a dumb relay that just routes blobs of data between clients based on how they are grouped. Correct?
If so, then nothing restricts you from relaying any type of data, which is a fantastic foundation to have.
Do you have any details on how two clients would establish trust, exchange keys, if there's a replay protection, etc.? It would make for a good read.
PS. One thing I'd change is the name. It's just... not nice, unpleasant. It also doesn't help that it means an "itch" (зуд) in some languages, the kind you get from not taking a shower for a month.
> That said and if I read you correctly, the backend must be some sort of a dumb relay that just routes blobs of data between clients based on how they are grouped. Correct?
You're correct. It is just a dumb relay. That's the reason why it's so difficult (impossible?) to come up with a freemium monetization strategy. The server can't see the contents of your communications, so it can't restrict functionality.
> If so, then nothing restricts you from relaying any type of data, which is a fantastic foundation to have.
I suppose so. What did you have in mind?
> Do you have any details on how two clients would establish trust, exchange keys, if there's a replay protection, etc.? It would make for a good read.
I don't have anything written up about this (other than the code in the repositories), but if there's interest, I could compose a blog post about it. For the time being, users can verify the privacy of the communication with another friend by comparing the safety number of the friendship (tap the friend's avatar on the map, in the info panel that pops up click the triple dots at the top right, then select 'View safety number'). If you're safety numbers match, you know your share with that friend is secure. I got the idea from Signal messenger.
> PS. One thing I'd change is the name.
Yeah, I'm still reconsidering the name. I've already changed the company name once, but I may have to change it again. It's just hard to come up with an easy to remember+spell name that also has an available domain.
I'd say that you may want to charge for the actual service rather than for relaying per se, but still base it off the quality of service. For example, will having near real-time updates of other people's location be worth $X/mo? Heck, yes. Should you charge for one-off manual checks? Probably not.
So, have a manual and automatic modes. With manual, if I want to know what my friend is, I have to tap a button and it will ask the relay to ask the friend's phone for its location. Cap this to, say, 1 request a minute and give this away for free. Then add an automatic mode whereby the relay will automatically poll my peers for their location. Charge for this. Also allow very easily enabling this mode for a fixed period of time, say, just 24 hours or 1 month or allow subscribing to it. This will take care of people who need to track someone's location only occasionally. Charge more for this (or, alternatively, give massive discounts to those who subscribe).
Next, have tiers on how often updates are collected. 1 minute, near real-time, etc. Price accordingly.
Next, cap the length of the peer list that people can have for free.
Next, on the server side retain only the last update by default, but allow retaining full (or extended) history. Charge for this, charge to the _consumer_ of this information.
Next, allow people organizing themselves into groups, with every one sharing their location with everyone else. Charge for that, charge it to the group owner.
Next, allow groups to have a "star" topology - all members reporting to a single "admin" user. This is now getting into the enterprise-ish use, so you'd probably want to have a "managed" version of the software that will have all UI locked down. This will also jive nicely with the history retention.
Next, add a separate management/admin software for herding group installs. Alternatively, offer an option of using a web interface in exchange for relinquishing the privacy.
...
I mean it's not that hard :) Start small, solving one specific need of a specific user group at a time and then extend logically.
Yes! I already use a non-privacy centric service like this, and would very much like to swap it out.
> Would you pay for it?
Yes. I'd be willing to pay $30/year for quicker updates. Maybe have a freemium model of an update per 30 mins or 60 minutes, a middle tier of 5 minute accuracy (good enough for most users) and then a premium tier of ~30s accuracy. Maybe play around with the amount of people in a group too - it makes sense to charge more if you're sharing with a small family versus a single friend.
As always with subscriptions, please make them have clear pricing, an option to pay annually (even if there's no savings) and allow auto-renew to be opt-in instead of by default.
On the monetization front, you likely can leverage the same infrastructure for an Enterprise version of the app. What many companies want is a rough geofence app that can let them know when someone is abroad for work and give them location specific information - "Oh hey, you're near the Ohio office. The alarm code is XYZ, and your badge has been given temporary access for the next 3 days."
Especially if you can assure employees that they're only giving rough location information to their employer ("Mary is in Nevada" and not "Mary is at So-and-so brothel in Las Vegas") then it feels like an acceptable tradeoff of information and benefit.
In truth, I'm trying to determine a pricing model right now via this Show HN. I don't intend to "yank the free version" from anyone. Maybe I'll be able to find a freemium model, maybe I'll be able to acquire sponsorships, maybe there will be a way to simply charge for it... I don't know. But folks that start using it now will be grandfathered in, so you don't have to worry if you don't want to pay.
I don't (and won't) have any investors that I need to satisfy. So there's no VC breathing down my neck, pressuring me to squeeze users.
I hope that's a satisfactory answer to your question and that it allays your fears. :-)
Regarding payment: I would get value from this, but primarily in conjunction with a higher-level service built atop it (providing features such as those mentioned above), and I'd want to pay for the higher-level service with this integrated, rather than paying for the building block. (That'd mean either you're providing the higher-level service and getting paid directly, or providing the building block and getting paid by the higher-level service rather than by the end user.)
Could you describe in more detail what you have in mind regarding "map integration and messaging/Signal integration"?
I totally get what you mean about triggerring events based on location (turning off lights, etc.).
The issue is that I wouldn't want to use a separate mapping application for that. I don't want to use Google Maps for directions/navigation/restaurants/etc, and a separate app for location sharing. I also don't want Google Maps to have my location information/history. I'd pay for an all-encompassing map service with this feature, and privacy would motivate me to happily pay for that even though Google Maps is "free".
But I can't honestly say I'd pay for just the location feature if I still have to use a different (and non-privacy-preserving) mapping service for everything else. If I can have a single "Maps" application on my device, and that application preserves privacy, I'd love to pay for that; if that app also has location sharing, that's even better.
Messaging or Signal integration would be for the same kind of "meet up" purpose: send someone a link that gives them time-bounded access to a subset of location information (most commonly live information about current location).
Yeah, I'd happily pay for a privacy preserving mapping app as well. While building this, I felt the need for such a service, and as I pondered it, I felt overwhelmed by the effort to bring such a thing to market. It would also need a significant amount of notoriety to get people to contribute by updating business and city information. The other challenge is that Google Maps is just SO GOOD! I realize it's not great for privacy reasons, but it's simply so easy to use and useful. That's a high threshold of quality and functionality for a new entrant in the mapping space to achieve. That's not even taking into consideration that this new entrant would be charging for something that Google gives away for free, and has had years to perfect. We can see an example of this struggle with Apple Maps.
> send someone a link that gives them time-bounded access to a subset of location information (most commonly live information about current location).
You might be happy to know that that functionality is already present in the app. :-) Simply click the floating action button at the bottom right of the main screen of the app, and a timed sharing dialog will appear. Toggle the switch to turn it on, and your location will be broadcasted to a drop box that can only be accessed by the key encoded in a URL that you can copy or share to any app (Signal or otherwise). You can adjust the expiration time of the link based as well. It's particularly useful if you're running late to a meeting and you're stuck in traffic, and you want to let the person you're meeting know where you are in real time.
Zood Location lets you share your location with other people without having to do anything on your part (besides accepting the initial friendship). Then your friend can simply open Zood Location on their phone and they'll be able to see where you are and you won't have to do anything. It's very useful for families trying to coordinate dinner plans after work, determining how soon your partner might be back home to help with the kids and other seemingly trivial things that usually require multiple disruptive calls and text messages.
> There might be better vistas in B2B.
That may indeed be the case. It's something I need to investigate further.
I was asked for advice on coming up with a solution and I had a tough time finding a good solution that is API-first, battery optimized, and has solid Android support, and a privacy-friendly DNA. We just need the real-time location tracking piece so we can use the information for dispatching them.
I think a private instance of the service might even be the most useful solution for you.
Personally, I would love to see a service like that. Even more if it had payments via crypto, so you can guarantee anonymity.
Sorry, but no. I might if I had small-ish kids, maybe.
As an adult, I would be wary of a service like that, and it would be outside of my comfort level.
I'd need assurances that the other parties who I trust today but maybe shouldn't (or don't trust tomorrow) won't be able to snoop on me, neither my current location nor historical locations the app may have collected, without my knowledge.
I could imagine something like a scheme where the data is double-encrypted. An outer layer of encryption where the key is known only by either the app or the server, and only revealed when the other party requests it, thus leaving an auditable action. The inner layer of encryption would still ensure that only the trusted parties could perform the final decryption step, or something like that. I am just spitballing here and this is surely not a finished, well-thought-out scheme.
That being said, I might consider using a self-hosted version of your software, but then I would only pay maybe 1 to 2$ a month maximum for it. But my use case is mostly location history, not real-time sharing, so it doesn't really match yet.
A case could be made that hosting an instance of OwnTrack with your location data in the clear on a VPS somebody else controls is less safe than storing it encrypted on someone else's server.
I'm not saying Zood isn't safe to use, but security isn't binary, and a centralized service is always a more lucrative target than a self-hosted one just because there is more data there. And it's also not just a technical question - what stops you from being acquired by $MEGACORP, pushing an update which removes the E2E and start mining the data? That (the acquisition, not the E2E removal) actually happened to me before[1] with a location tracking app.
[1]: https://www.pcmag.com/news/facebook-acquires-fitness-trackin...
If Zood offers Moves-like location history in the future, it will also provide a method for exporting the location data to CSV or similar (data portability).
Perhaps to track my grandma, who lives alone. Or on festivals or while skiing with friends. Not in everyday life.
> Would you pay for it?
Yes, but I would prefer a solution where I host a server myself to be honest. I would more gladly pay for a license here instead of a service with monthly costs. In reality I have some dev friends and if it was a feature we really wanted, we might hack something ugly together ourselves. But for commercial use I would do pay for it.
> Would you or your company sponsor it?
No. I am in a position where I could influence such decisions in the company I work for, but I think it would just lead to employee surveillance, which I don't support. My boss might, but I would recommend to refrain from doing so and would gather arguments against it.
I know it is common in logistics, but that shouldn't mean everyone has to accept such tracking. Poor souls...
The benefit of this would be that you could ask your family members to install it on their phone, for emergencies. And if you have a teenage kid who is concerned about you "stalking" them or "invading their privacy", you will be able to say, "you will be able to see in the app whenever I look up where you are, so you will know that I'm not checking up on you constantly"
It would also be a deterrant against you abusing your powers. You wouldn't want to look up where they are unless absolutely necessary, as you wouldn't want to create that log entry on their phone, as you'd have to explain it.
Free idea, for anyone who wants it.
Some of the features I got requests for were: tracklogs/history, geofencing, possibility to automate start/stop, overview web page for fleet tracking and so on.
I just tried the app and love the high quality feel of it and I think the amount of features in the MVP should already cover the needs of most people for the free version.
Out of curiosity, how often do you update the location? I couldn't find any setting for that.
Source: built https://graticule.link/ to scratch my own itch, tried monetizing it but gave up since it would have needed to go in a direction I didn't care about.
PS: The email verification page is blank.
> how often do you update the location? I couldn't find any setting for that.
There's no user setting. On Android, I rely on the Job Scheduler service, so the most the app can be woken up is once every 15 minutes (less if the Android OS feels like it). However, there is also a BroadcastReceiver set up to receive locations when another app requests it. Lastly, a friend can request an update if it has been more than 3 minutes since the last update they've received. When they request the update, a Firebase message is sent to your phone and a service is started immediately to grab your location and send it back to your friend. The reason for all this fuzzy timing is to maximize battery energy. The alternative would be to keep a foreground service running all the time, but I've had complaints that people don't like seeing the service notification there and they don't want their battery drained.
In the (currently unreleased) iOS app, it's a similar set of of fuzzy conditions.
> PS: The email verification page is blank.
Thanks, I'll check that out.
Nice. I think this fits the infrequent updates scenario of the app very well.
> The alternative would be to keep a foreground service running all the time, but I've had complaints that people don't like seeing the service notification there [...]
Interesting, to me the periodic "updating location" notifications are way more jarring. Especially since Android allows the user to minimize (only visible when you pull down) or even hide the notification completely.
But yes, I definitely received this complaint a lot, but for me this was a no-go as I don't want people to be able to use it as a stalker tool (e.g. install on victim's phone without their knowledge).
I want to iterate again how polished the app feels, so you definitely have yourself a new free user :)
The way it solves the permanent location sharing feature is really nice and will try it out in a bit harder conditions (mountains with degraded signal).
I don't know if I would pay for it, maybe if it would be possible to pay as a family/group.
Two bits of feedback if you don't mind:
1) I only realised the other day that the tracking link didn't automatically change between activations (I now realise I can do it manually).
2) When meeting up with someone in the middle of nowhere recently, I noticed that it'd show their location on the map, but not mine. As I didn't know where I was, having a blue dot of my location so I can estimate their distance would be really handy.
Thank you again :)
> I only realised the other day that the tracking link didn't automatically change between activations (I now realise I can do it manually).
Hmm, good point. I wouldn't automatically reset it for each session since there are people using it for multi-day stuff.
Would having a "link last reset at" timestamp in the main screen would have helped you realize that earlier?
> When meeting up with someone in the middle of nowhere recently, I noticed that it'd show their location on the map, but not mine. As I didn't know where I was, having a blue dot of my location so I can estimate their distance would be really handy.
Initially I thought that might be sketchy -- "why does it want to know MY location? I just want to watch" -- but perhaps making it a button/setting would be a good compromise? So something like a toggle for "show my location" on the webpage?
> When you're all about an hours drive away in different directions it's really handy to keep track on people's progress without disturbing their driving.
This is perfect because I've been trying to build a feature where you can combine multiple tracking links into one, and you see everybody on the same map. Where I always get stuck though is the UX.
On a computer it's pretty easy to have a page where you paste all the links and it generates a combined one, but I can't figure out a good UI/UX for doing this on mobile.
So if I can pick your brain for a bit... do you have any insights here?
How do you usually send/receive these links?
Would pasting them all on a page work for you on mobile?
Any better ideas?
Either a "link reset at" or even just a note on the share link page saying "this link stays permanent between runs unless you choose to reset it" would be OK I guess. The only reason I realised it didn't change is because on arranging a meeting with friends recently, they said "oh yeah, i've already got that link, you sent it to me last time".
Entirely my own fault and own assumption... Maybe even a settings option to "preserve tracking URL between launches" or an option for "URL times out after xxx hours/days".
A togglable "show my location" would work fantastically for my use case. Even better if it were to show me a distance (20 miles away as the crow flies is still useful information if you're waiting for someone to arrive, though obviously doesn't take into account distance or time by road).
Multiple users on the map would be fantastic (I really do miss lattitude). I can't quite imagine how that would work without an immense amount of extra work. At the moment we tend to just share the URL via a facebook message, me having to paste multiple links in would work fine for me, but I can see less technical users having problems.
I guess in an ideal world, viewing someone elses graticule link would open in the app rather than the webpage. At that point clicking multiple links for different people would just add them all into my copy off the app so I could see everyone moving around just by opening my copy of graticule rather than keeping track of other people's URLs. Combined with an ability to set a lifetime on the link we could all generate a 24h tracking URL in the morning, post them all into a group chat and then it's just a few clicks for me to correlate them all together into the app (and then have them auto-remove as the links time out).
Having multiple maps on screen on the computer is acceptable if I'm just tracking multiple people (eg different delivery drivers); eg their actual location only matters to me. The second I have more than one person trying to meet up (even if it's me and someone else), then having disparate maps is a pain. As one tends to want them rather zoomed in I'm having to expend a lot of mental effort in trying to work out where each location is relative to each other, rather than reality. If it's an area of the country where I don't recognise village names then I'm having to crossreference a whole lot of information and keep it all in my head (and I'm stupid with a bad memory).
Hope this feedback is useful. I feel quite guilty about the fact I've suggested a tonne of work for yourself for the sake of making something I use for free easier for me, which doesn' seem entirely fair :)
Also another way to avoid using google / apple location services is offering a geoIP mode, which would mesh well with the optional rough location options.
It's too bad you can't force location services to only use built in GPS vs pinging their internet servers.
Apple also has an issue where they silently stop location tracking apps in the background, you might have to make a nag notification like arc app does do to keep it active. https://www.bigpaua.com/arcapp/
I don't have a formal list set up for this, but if you would like to be notified of when the iOS app is ready just send me an email [arash at zood dot xyz], and I'll send you a reply when it's ready.
> one idea that would be cool is to set the accuracy of the shared location
Great idea. I hadn't considered that. Using geoIP mode would also be worth investigating. I've often found geoIP to be quite inaccurate when on cellular networks (e.g. reporting that I'm in San Jose when I'm actually in Los Angeles). Any thoughts about that?
> It's too bad you can't force location services to only use built in GPS vs pinging their internet servers.
My understanding is that on Android if you only use the platform location services instead of the Google Play Fused Location Provider, it will only access satellite positioning (GPS, GLONASS, etc.). It will also use up your battery faster, but I think that's tangential. So, at least on Android, I can code a path to only use location services.
> Apple also has an issue where they silently stop location tracking apps in the background, you might have to make a nag notification
That has been a real pain in my side on iOS and Android. So many deceptive apps have abused the location system for so many years, that Apple (especially) and Google are making legitimate use cases of background location very inconvenient. I can't say I blame them either.
You could even go full original whatsapp and add a status string thing :P
Unless I'm missing something, couldn't you just fetch the GPS location and truncate the precision to 1/2/3 decimal points? There are subtler ways of doing this that mitigate
A: Oscillation of a user on the border between X,Y and X,Y+1
B: Distortion of precision area near the poles
but I'm sure you get the gist.
What we have found is that the average customer doesn't really understand privacy. They would likely not understand the difference between this and any website that puts the "256 bit SSL encryption" blurbs on checkout.
We are not a privacy first service per se, but do want to give users full control over their data, so let them opt out of things like a partnership we have where we analyze their driving data to match them with car insurance. Very few users take advantage of these settings.
I don't say this as a knock on the idea at all, but am sharing my experience of serving consumers outside of the tech scene. I wonder how you could package this value proposition for an ordinary user?
> What we have found is that the average customer doesn't really understand privacy. They would likely not understand the difference between this and any website that puts the "256 bit SSL encryption" blurbs on checkout.
I totally agree with you. I'm just focusing on building an easy to use service, and the cherry on top will be the privacy guarantees, and right now that guarantee is a big deal because I'm introducing it to folks on HN. :)
Location sharing not particularly useful for me on a day-to-day basis, but I love it for family/group travel and outings.
As a consumer, I would pay for it but my sporadic usage probably has me looking at a low price point. And our company is so small we don’t have a use-case for it there. However I can think of a slew of businesses that would find it worthwhile.
Keep up the great work! Love your vision as a company and looking forward to seeing what else you have in store.
- Matt (from UserKit)
Could you describe in more detail what kind of integration you're considering? Would you just want to be able to see your friend's location published in a channel as they move?
I could honestly ditch the periodic updates component of this, provided "request location" was always available.
I saw the web site has a laudable privacy policy. Do you have a published privacy policy for the app?
[1]https://reports.exodus-privacy.eu.org/en/reports/hr.ersteban...
Zood Location's app id is 'xyz.zood.george'. The only thing they have in common is the word 'george' in their app identifier string.
Zood Location also has a privacy policy. [2]
This would also let you work around the network effect: simply send a text (for people without dataplans but infinite text) or an email with the GPS coordinates + a link to the google map (or OSM, or bing maps..) in one click. Not much data required.
Even better: add a "tracking" mode to automatically send the coordinates every minute, as an email reply (to create a thread) which could be useful when you are going to roam the bars and don't want (or won't be sober enough) to update your friends of where to meet.
I would also like GPG encoding: again, to work around the network effect, GPG encode the email before sending it. Useful for emailing myself or hacker friends.
I would seriously pay for that, especially with the option to run the AGPL backend on my own server (the client should have a field to optionally select another server)
So far we've always shared via Whatsapp which recently stopped working for some reason. But I also don't want to use Google maps or Whatsapp for privacy reasons. If you could find a way to make 100% sure Google won't "intercept" the location and store it anyway, that would be great.
I'd use it probably 3-4 times a week. I'd be happy to pay for it but please don't do the standard 10 bucks a month thing, I won't even bother then. How about a model based on usage? 10c/hour or something for the one sharing? (Being shared with could be free). If I had to commit to a subscription, I'd probably not sign up if it's more than 2 bucks a month.
* https://thoughtfunction.com/2020/05/my-e2ee-apps/
* https://thoughtfunction.com/2020/05/e2ee-note-taking-app-res...
I think being privacy first as a company is great, but I'd like to understand a bit what that actually means in terms of differentiation. My assumption is that many players in this space (particularly those targeting families) are not selling my data. Is that a false assumption? If so, say so on the landing page. If not, how are you different?
Not trying to be a party pooper, just know from my experience building my own company these days that not being crystal clear on differentiation when playing in crowded spaces gets you beat up.
Otherwise you are just using the google/apple geo service. Granted this approach would work best in urban areas and wouldn't work at all in unpopulated areas. You'd need to fall back to GPS or the OS location service in some cases.
I don't know if this is practical, just an idea from a privacy conscious individual.
> Only people on this list will be able to view your location, and it will be safe from advertisers, rogue employees, hackers and nosy governments.
I think you'd be hard-pressed to guarantee security against a nation state. Even if it's "the government is tracking your SIM on the cell network," it's a pretty bold claim that your threat model includes well-funded government actors.
Glad you like it!
> I think you'd be hard-pressed to guarantee security against a nation state.
My intent with that statement was not to mean that one would be protected from a nation state that has turned all its attention to you. I think that's an impossible level of security to guarantee. Signal could not even guarantee such a thing. The intent in the statement is that "a government agency can't simply send Zood a National Security Letter or some other coercive legal document and expect Zood to turn over location data about users". And that's because Zood doesn't handle user location data; there simply isn't anything to be turned over.
The goal with Zood is to create software that allows regular people to conduct their digital lives without giving up all their privacy and dignity. To prevent further expansion of the surveillance economy. The goal is not to build software that defends wanted individuals (whether right or wrong) from nation state actors. That's not something that I think any single technology company can provide.
* Long build finishes on my PC. Send me a message on the phone.
* Log watcher detects an issue on a server. Send me a message.
* CI job fails. Same.
* Some notification pops up in my laptop’s browser. Forward it to the phone.
Last time I looked at apps doing this, they either did not appear particularly trustworthy, or were too limited.
Bonus points for an ability to import from Google or some CSV, at least.
I'm an iOS user and so are most of my friends. It would be good if you added a little thing to your site to let me sign up to be emailed when it's available to try out.
If you want to send me an email [arash at zood dot xyz], I'll send you a reply as soon as the iOS app is available. Don't worry — I won't put you on any mailing lists. I don't even have the energy to create a mailing list. :-p
However, with Zood Location, it's probably more likely that the map tiles will correlate to where your friends are. At least that's the way it ends up working out for me.
I'd like to host my own tile server in the future, but it depends on revenue, which is just not there right now.
Also, and this is just my opinion, I don't think Google is trying to surveil people via tile loading patterns. I'm not saying it's impossible, but there are far easier ways to surveil users than examining tile loading patterns. So for the time being, I'm ok using the Google Maps SDK.
Privacy, like trust, is not binary, but a spectrum. My hope is that Zood Location can start increasing the amount of privacy people enjoy in their digital lives, and over time, the app can be improved to increase that level of privacy.
But if I could just do that, and with no further admin overhead, contribute to some sort of tile-cloud, I'd find that a lot more meaningful than seeding my favorite distro's torrents, you know?
In the iOS app you can also add an option to use apple maps instead too.
The public key model appears to be TOFU [4]. It's doing a distinct crypto_box per notification [5]. It doesn't use an authenticated key exchange or offer key rotation or forward secrecy, but that's probably fine for this use case. Not too long ago, I wrote a guide to end-to-end encryption [6], and I would classify the "end-to-end encryption" here as meeting the minimum definition (data is encrypted between devices, rather than in a client-server architecture where the server has access to plaintext), even if it's not suitable for more sensitive threat models.
One thing I didn't see was message padding of location data prior to encryption, to prevent side-channel attacks via ciphertext length. [7] I don't know if I missed this, or if it was omitted.
[1] https://github.com/zood/george/blob/52ddae2b5f65d324e1785c2d...
[2] https://github.com/zood/george/blob/52ddae2b5f65d324e1785c2d...
[3] https://github.com/zood/george/blob/52ddae2b5f65d324e1785c2d...
[4] https://github.com/zood/george/blob/52ddae2b5f65d324e1785c2d...
[5] https://github.com/zood/george/blob/52ddae2b5f65d324e1785c2d...
[6] https://soatok.blog/2020/11/14/going-bark-a-furrys-guide-to-...
[7] https://ioactive.com/ssl-traffic-analysis-on-google-maps/
You're correct that it doesn't offer key rotation or forward secrecy. That's something I definitely want to add (assuming anybody actually finds this service useful).
> One thing I didn't see was message padding of location data prior to encryption, to prevent side-channel attacks via ciphertext length. [7] I don't know if I missed this, or if it was omitted.
You didn't miss it. It's not there. It's something I should add.
https://github.com/soatok/rawr-x3dh
There's no low-level crypto code here, just high-level protocol stitching. This is still something you'd want to hire experts to review if you built it in Java, of course.
It's on my TODO list.
* Usage of the Google Maps SDK - the service needs revenue to be able to support running and maintaining it's own tile server
* Usage of push messages via Firebase - the zood server has no problem with a socket remaining open all the time with the Android app, I'm simply not sure what the impact would be on the battery.
* Usage of the FusedLocationProvider API - a code path needs to be added that would simply use the platform provided GPS access. It wouldn't be too difficult, but it would hurt accuracy and battery life.
* Usage of locationiq.com API - similar to the need for a Zood tile server, I would need to stand up my own reverse geocoding API somewhere so F-Droid wouldn't need an API key for locationiq
That all said, I do think it's a worthwhile endeavor to make the app F-Droid compatible. I just can't provide any guarantees about when that would be.
This could be done in a querystring argument in the shared URL hash: &geocoding=false
In short, there's no custom cryptography in the service. The core crypto is all performed by libsodium.