I don't see why apps like that should give you an exact distance instead of some rough estimate.
"X is a few miles away", "X is less than a,mile away", "X is several yards away" (which is, say, within 30-50 yards) — and more precision is not needed. If users want contact, they need to explicitly coordinate.
This approach, of course, should not be centered on the exact user location, but use some rough and slightly irregular grid, so that the best one could do is to determine the cell of that grid (again, like 50 yards wide), without any idea where in that cell the target user is.
This, and query throttling so that scanning more often than once in 5 minutes isn't possible.
It’s easy to measure statistics of a device noising among several grid cells to find with high probability the exact coordinate. Think of a person standing right where grid lines intersect, so with 25% probability each time the position will be reported to be one of four neighboring cells (due to errors in GPS measurement), which gives their exact location right on the intersection. If the probability weights’ distribution is different, it’s easy to infer the coordinate as well. Or if the person is moving, you can build their trajectory with high confidence.
It’s not that easy to obfuscate the coordinate in a way that the position is still relatively accurate (for the purpose of distance), and not “hackable” with some basic statistics.
At one point I was working on a project with user locations/distance sharing.
My solution was just to Math.floor both of their lat/lng to be in increments of .25 miles. You could still use the triangulation trick to find that point, but .25 miles seemed like more than enough to obfuscate things.
Had I made the display in increments of miles only, that would have probably been even better.
Tinder actually has a fairly interesting solution to this, they divide the world up into mile grids and use those. Funnily enough, a blog post by the same writer as OPs link.
This is a trick I use when doing competitive analysis for a certain type of sensor. I need to measure the amount of noise in the system, but a dead-band or quantization is almost always included. So, I insert a signal that bumps up against the boundaries of the dead-band or quantization. Doing this repeatedly gives me a sampling of the noise.
This seems like a potential use-case for differential privacy. Normally DP is used for protecting individuals within aggregates, but the careful analysis of how much (and what kind) of noise to add could be brought to bear here.
What about a constant, random, per-match offset? An error applied to a match's position that can't be averaged out, because it is always wrong by the exact same amount. Use a different error in a different direction for each unique match so one can't figure it out once and apply it system wide.
I suppose the downside is that this could put someone else at risk if the tweaked position happens to be on top of their house.
1. The attacker can use multiple accounts to collect data, so an offset specific to the viewer wouldn't work
2. If you can collect the offset location over a longer time, you can correlate it with likely travel paths (e.g. along major roads) to figure out what the offset is.
If you knew this was happening, you’d create N accounts, match with the same person, and average queries over account pairs.
Also, if the error is constrained to be the same, then the attack is reduced to estimating the radius of a circle where you are given points on the perimeter, which you should be able to do in very few queries (3?). I haven’t worked out the triangulation math but you’d basically solve for x^2+y^2=r^2.
Yeah, its an overcomplicated, breakable solution. Just decide the minimum safe uncertainty, assign grid cells that provide it, and only report distance quantized to grid cells.
Every time this comes up a hundred people decide you "just" need to quantize, and that does help but is still vulnerable in multiple ways, including if you have low "valid location" density (think a grid cell that is 95% water) or if you're on a boundary and flip between two cells. It's easy to mitigate the normal case but takes more thought to mitigate the edge cases.
> After some trial and error, Kate realizes that Bumble doesn’t round its distances like most people were taught at school. When most people think of “rounding”, they think of a process where the cutoff is .5. 3.4999 rounds down to 3; 3.5000 rounds up to 4. However, Bumble floors distances, which means that everything is always rounded down. 3.0001, 3.4999, and 3.9999 all round down to 3; 4.0001 rounds down to 4.
How exactly would you figure that out? Of course once you have a full working solution it's easy, but how do you distinguish this when you're just tinkering with it?
My solution: Group people by zip code, give distance ranges based on the two users' zip codes.
Within same zip code or two zip codes that border each other? "0 feet to (farthest distance between any two points within zip code(s))"
Zip codes farther apart? "(closest distance between any two points within zip code) to (farthest distance between any two points within zip code)"
No need to limit queries, no need to fuzz anything. No way to triangulate unless one person happens to live at the corner of three or more zip codes, in which case you could just pin them to one zip code as long as they are within a certain range of that zip code.
In areas where zip codes are unusually large (Alaska?) or unusually small (NYC?), you can substitute in some other chunk metric.
I think we went over this when the telegram version of this hit HN a while back.
It just doesn't work.
For zip codes for example: There are single street zip codes (aka postal codes) all over Canada. And I'm not talking a large boulevard that goes across town. Literally one street that I can see one end from the other on easily.
Sure, but you could detect zip codes that are under a certain length and/or area, keep combining them until they are large enough. Zip codes are just a starting point, the concept would still apply. Group people into sufficiently large chunks, only reveal their chunk. It could be a grid instead if that makes more sense, but I imagine zip codes make use of borders along rivers and other forms of convenience.
Your try to make it less easy to find someone also makes it less good for the intended use case. Suddenly the app can only tell you if someone is in the same town or not because we combined the heck out of zips.
But the you realize that at the edges of whatever combination you chose you can find if someone is on one side or another of those areas. And these areas have borders on many sides so many cells to triangulate with and play the "are you here or on the other side".
So basically both requirements fight each other and guess which one won and what the results are.
Yeah it seems that in this case, Bumble obviously went with exact locations and failed to fuzz it.
It's been a long time since I've done online dating, and back then long-form OKCupid profiles were the norm, but instead of a distance radius, I always wished could draw a shape of interest roughly correlated with my local subway map and places that were convenient to walk to.
Besides limiting requests to the match group, they could save the distance at match time, and just show that. Once you match, the distance doesn't matter.
So the exact same triangulation vulnerability exposed and subsequently fixed in every dating app? How is this not Step #2 after “Build a dating app that Match Group will eventually acquire”
Not just dating apps, but really _any_ app with location based chat. Telegram hit the top page of HN a few months ago with a similar vulnerability[0]. There's other apps that sell this as a feature! Snapchat does this and you can see people down to the exact corner of the street they're standing on. Ads (used to) allow you to do it too[1]
I am not very knowledgable about security bounties, but 2k seems laughably small. Every female using the app was gravely in danger because of this bug. There are a lot of creeps on dating apps. That it got awarded just 2k and no resignation of CTO is a joke
> Every female using the app was gravely in danger
You left out a very important key word, "potentially." The article did not say a single person out of millions using Bumble was actually attacked via this method.
Gravely in danger, for all 18+ (within the US at least) is a bit of a stretch.
You can find the current/last known address of nearly any registered voter with a simple Google search. I'm not exactly sure why or how, but you can.
There are also services, that aren't exactly expensive, in which you can buy the phone number or address of nearly everybody in the U.S.
If you think being able to triangulate and pinpoint the location of somebody via a dating app constitutes grave danger... Well, there are much graver dangers that can't be fixed by any $ bounty all around us.
I'm not trying to say that what happened with Bumble isn't bad, and it makes the company look somewhat foolish, but in 2021, finding the location of somebody in most developed countries, aside from your ultra secure OPSEC average HN user, is quite a simple task.
I agree with the sibling comment that the key word is "potentially," but disagree with your sentiment that "I haz whitepages, game over" since the difference is that ones voter record address does not travel with them everywhere in their purse/pocket
To further illustrate the point, I believe trips to Tahoe are a non-trivial source of hookups, but being able to follow a potential match back to their chalet is not something anyone would voluntarily opt-into
Crime is not difficult. Every woman is already in danger. As is every human. Every animal. The world is dangerous.
If level of danger caused by a company was proportional to punishment, then every gun or tobacco (secondhand smoke) or fossil fuel company would have to have everyone in the org resign effective immediately.