3 ms·
Due to the fact that distance matching is done server side the application doesn't have any knowledge with regard to distance. The only knowledge one has is whe
by theveloped 10y ago
Due to the fact that distance matching is done server side the application doesn't have any knowledge with regard to distance. The only knowledge one has is whether or not one receives messages from an other user.
Using triangulation to pinpoint an other users location would therefore require to move in and out of range (while the targeted user is continuously sending messages). Thus significantly more difficult than if the actual distance measure was depicted in the UI or leaked elsewhere.
Finally closing the API to outside requests limits the ease with which the above could be automated. Any idea's for further improving these security measures are most welcome!
- mseebach 10y ago> would therefore require to move in and out of range (while the targeted user is continuously sending messages). That, or a number of co-operating clients located at various locations in and out of the range. A simple fix would be to have every sender generate a random vector of random length 0-100 meters (and re-generate every time you've moved at least 100 meters, you don't want to regenerate if the sender doesn't move as you'd be able to zero-in on a prolific sender), and have the message "originate" from the end of that vector.
- pavel_lishin 10y ago> Using triangulation to pinpoint an other users location would therefore require to move in and out of range (while the targeted user is continuously sending messages). Or spoofing their actual location.
- tghw 10y agoHow exactly do you close the API to outside requests? It's not hard to reverse engineer most APIs, either by decompiling the app or just watching the wire.
- tokenizerrr 10y agoYou don't. That is impossible.
- bo1024 10y agoI can't tell how it works from the site, but a good approach is to randomize the distance threshold a bit each time. For example: if users are within 1km, always connect; if more than 2km apart, never connect; 1.xkm apart, connect with probability x. That kind of thing combined with some rate limits (how often one can attempt to connect to a user) should be effective. (edit) Actually, I think I like mseebach's suggestion even more: For each user, pick a random location about 100m away from them, then pretend they're there until they've moved far enough away, then repeat.
- civilian 10y agoHeh, it's like salting their location.
- yarou 10y agoBelieve it or not, but this is exactly what the Chinese government mandates. It's known as China shifting[0], and can cause quite a lot of headaches. [0] https://en.m.wikipedia.org/wiki/Restrictions_on_geographic_data_in_China#The_China_GPS_shift_problem https://en.m.wikipedia.org/wiki/Restrictions_on_geographic_d...
- bo1024 10y agoI'm thinking of ideas like [differential privacy](https://en.wikipedia.org/wiki/Differential_privacy https://en.wikipedia.org/wiki/Differential_privacy).
- rawnlq 10y agoI am not sure if your original solution will actually work. For example an attacker can just spoof enough accounts to sample from your distribution to figure out the true center. Imagine spoofing a grid of users with let's say K fake accounts per dot, then if you plot the histogram of who managed to connect you will see a very clear bump in the 2d histogram in the shape of circle. The solution in your edit is much better.