How I was able to track the location of any Tinder user | Hacker News Reader

How I was able to track the location of any Tinder user

blog.includesecurity.com

180 pointsrkudeshi70 comments

It's a horrible shame that many developers don't think through the consequences of their implementations before publishing services that trade in personal information. The technique published in this disclosure, as well as the fact that the service sent users' exact coordinates before July, should have been some of the most obvious concerns in building a service that shares one's picture while purporting to keep one's identity and location hidden.

Is Tinder still sending date of birth instead of a calculated age, like in the API example? It seems that no one there has given any thought at all to this topic other than to splash some water at the earlier fire. (IncludeSecurity, could you let us know whether Tinder is still sending the birth date data?)

I can understand that many people don't think through the consequences of sharing personal information, but it's hard to believe how many developers dealing with other people's information give it so little thought as well.

> It's a horrible shame that many developers don't think through the consequences of their implementations before publishing services that trade in personal information. The technique published in this disclosure, as well as the fact that the service sent users' exact coordinates before it, should have been some of the most obvious concerns in building a service that purports to share one's picture while keeping one's identity and location hidden.

Not taking trilateration into account may have been a careless mistake. Sending literal GPS coordinates, however, means the developer probably didn't care.

The exact-coordinates debacle should have been a wake-up call to examine and put some thought into the data that the service sends to users. In fixing the issue, someone should have asked "should we send a ridiculously precise number, or should we perhaps send an approximation to a mile or a tenth of a mile?". In that review, they should have decided not to send the DOB as well. It wasn't a small, new service at that point.

Oh, I totally agree. My original post wasn't clear :

In isolation, this vulnerability could be chalked up to carelessness. Coming on the heels of another even more egregious vuln, however, it (IMO) speaks to a IDGAF approach to privacy and security.

Yeah, but it's not always easy to see every possible security issue. For instance, your proposed solution of just rounding the distance to the tenth of a mile is scarcely better. The attacker will just need more than 3 points to be able to locate with as much accuracy as they want.

At least I hope that's not how this issue was fixed; article doesn't say.

> For instance, your proposed solution of just rounding the distance to the tenth of a mile is scarcely better.

I didn't propose rounding the distance as a solution--I mentioned it as an example of the kind of thought that should have started taking place in the mind of someone who was looking to fix the real location issue rather than making a quick change to stop complaints.

> but it's not always easy to see every possible security issue

The quality level of the original fix, in which they sent extremely precise distances, indicates that they put approximately 0 thought into analyzing the issue. It may not be easy to see /every/ possible security issue. But seeing many of them at all requires looking, and it appears they weren't doing much of that. They were getting some serious bad press in July, and their solution was a band-aid rather than an examination of their practices.

The solution may not be obvious, but the problem, especially once brought to one's attention, should have been. It's built into the nature of what they're doing, which makes it especially disturbing that they didn't care enough to put some more thought into it. Their response to the person who reported the problem reflects that as well.

Maybe it was originally viewed through a performance perspective only, with the idea that all of the data crunching should happen on the front end to provide a faster server response?

Just rounding a location integer can be done in less than 10 assembly instructions. May be the time spent on that can well be compensated by transferring less data (orginally we transfer a float now we only transfer an integer).

Anyway, the point is processing this one sensetive information on server side really take little time. Maybe only several nanoseconds? The network latency is the botttleneck, not the proceesing of several bits of data.

This is something the phone of each user itself could do. All that is necessary is for the app to generate a random offset for the latitude and another one for the longitude at startup then report their location + constant offset instead of their actual location to Tinder.

Now the worst thing that will happen is someone triangulates a point say, 1/4 mile away from you.

The biggest privacy vulnerability for dating services is a simple reverse image search. The majority of users use the same images for their dating service as they do for every other social network.

Once you've found their Twitter/Instagram/whatever, then you have a name. Now you have their Facebook profile.

Also, once a person gives you one bit of information it becomes infinitely easier to find them.

Especially with the facebook graph search you can do something like: "women who live near me named _____ who like _____ and graduated from ____." And then you have their facebook profile...

I am still sort of shocked that facebook just allows anyone to do this.

To be fair, that is (was?) the entire point of facebook. Allowing people to connect and answering the question "Remember that girl "Jane Doe" from college, what is she up to?" was basically the killer feature.

That's a far cry from "show me all female friends of my friends near me who are single and like the walking dead" or "all males in nyc who work at X company and use tindr app".

Facebook gives zero privacy to anyone using it. If I walk into a coffee shop and see someone interesting working there, I can just run a graph search and page through the results until I have their entire life history online.

Wow I didn't know you could search apps too, it appears you can see all apps someone uses "Apps used by <name>". I guess that could avoid the awkward moment on dates... "Hey do you like Candy Crush?"

Hence the 'See all friends using the Bang with Friends app' incident.

The problem of reverse image search is also magnified by Tinder only allows users to display images from their Facebook profile on their Tinder account.

If their fix uses random noise per api call they are again vulnerable (just take the average of the each result).

Also again reduced precision on the reported distance won't fix the issue, you can sweep the map for changes in the last digit (by changing the attackers reported position)

They must reduce the precision of the users input not the reported distances precision.

ps. the problem in here is the accuracy not the precision

They must reduce the precision of the users input not the reported distances precision.

That's an interesting idea: randomly perturbing a user's reported location.

I've been developing a social network app that, in v1 (development was outsourced to someone else), sent the distance to a particular profile (I'm not sure how accurately). In v2, I wasn't sure what to do so I've left it out, but it's currently at number 3 on my TODO list.

In our case, it's pretty important to be able to do location sorting client side. We have the geo extensions for SQLite and are intending on using that.

So, question: if I randomly perturbed user's locations reported to the server by anywhere from 1-5 miles, would that be sufficient to ensure privacy, while also enabling the app feature, which only needs precision at the level of a few miles?

UPDATE: I thought about this some more, and what I'd do is the following:

1. Take the location of the device and make it imprecise, but accurate. For example, it could be anywhere within a five square mile radius, but it really would be within that radius.

2. On a per-user basis, pseudo-randomly but deterministically perturb the imprecise location for that user, to generate the stored location.

The second requirement is to prevent averaging multiple location updates for the same person over time, to pinpoint a location. Each user would have a different random, but deterministic offset for each five square mile area on the globe.

The perturbed location for that device in that area would be the same for everyone, so you wouldn't be able to merge the output of multiple users "view" of that device's location to increase accuracy, either.

I'd appreciate any and all feedback. Thanks.

It really depends on what your trying to do - you might be overthinking it. I think rounding all inputs to the nearest minute or two of latitude and longitude is probably sufficient for most cases... Basically, treating the world as a grid of some sort, and dealing in exact points at that level.

This sounds like the correct, and simple, way to do it.

This is a really beautiful hack. Not just some SQL injection run-of-the-mill vulnerability. Very clever.

Thanks, these are the kind that we find every week. We also get bored of the SQLi/XSS treadmill....it's much more fun to find a parsing error that leads to a crypto vuln that bypasses authentication (hint hint for a future blog post)

Another enormous hole in app privacy is that mobile devices tend to store location and compass bearing in addition to handset model in every photo taken with the camera.

So if you run a web or mobile app, scrub these on receipt by re-rasterizing (load .jpg/png -> copy image data -> save to a new file) using something like ImageMagick.

Tinder should never known the users exact location anyway. They should be asking the device for a far less accurate coordinate.

How could you even prevent this vulnerability?

As long as the undocumented API is publicly accessible, and Tinder intends on reporting a users distance to each other (4.5 miles), it will always be possible to triangulate the position.

The only thing I can think of is to obfuscate the user ID in a way that you cant use the ID to guarantee a lookup of the same user.

I think it's a matter of precision of the distance measurement. If they round to the nearest mile, then the possible location is basically square mile (technically circle - closer to .8 sq miles), which is less of a privacy concern.

I thought Apple's Find my Friends app had a built-in 'fuzz my location by...' setting where you could do 0, 0.1, 0.2, 0.5 etc. miles. I can't find it now though and am possibly therefore misremembering it as something else.

Either way, it's trivial to take a lat and long and randomise a +/- on each value, or alternatively if you want a ciruclar error randomise a magnitude and angle and resolve the shift to lat and long.

Instead of having the client use the distance data to filter out people within a certain radius, the server could do the filtering and send back the result.

Of course, you could probably do a lot of requests from different locations and intersect the results to find a more accurate position of the target with this fix too, though with some randomness to each request on the server side it will probably make it not worthwhile.

That's some good work. It's a pity Tinder barely acknowledged the assistance.

The lack of acknowledgement to the researcher is pretty shitty. I'd expect it will really hurt Tinder's chance of their next vulnerability being responsibly disclosed.

Their "fix" will do nothing to prevent location information leaking. Making more accounts and getting more distances will increase the precision just as seeing more satellites increases GPS position. No matter how much noise they add, they will always be vulnerable to this attack in the same way with enough time, even the most subtle timing attack will be exploitable.

There is a way they can fix it properly though. What they need to do is report the actual position of the user, not the position relative to a position you give it. This may seem less secure but if it gave that latitude and longitude to within 3 miles, for example, it would be impossible to locate a user more precise than that.

Idea on top of this: allow a user to pick a landmark or location they want to represent where they are like a university or park, so that its not their actual location being given out, but rather something meaningful near where they usually are from day-to-day.

Yeah they should resolve the location to a geographical name. What value is there in the distance then other than, oh I can walk over to your house for casual sex instead of taking the bus. Oh I see...

"January 1st 2014 - We look at the server-side traffic to see if the same issue exists and see that the high precision data is no longer being returned by the server (awesome looks like a fix!)

"February 19th 2014 - As the issue does not seem to be reproducible and we have no updates from the vendor....blog post published."

So, this has been fixed now? The rest of the post wasn't very clear about that.

sorry I added "which has since been fixed" to the first paragraph. We like to write C and Ruby langs, still getting used to this English lang.

s/seen/since/

thnx sigh words

I was actually messing around with something similar (using only the radius information) a couple of weekends ago. In case anyone is curious. Node project just pushed to github:

https://github.com/tmsh/guess-city-on-radius

So why again isn't this personal information transferred over HTTPS? Secure connections should be enabled by default for every webservice or API, ever. For starters.

I love that they published a "Vulnerability Disclosure Timeline" and waited for the company to patch the vulnerability before publishing this blog post.

Just curious, would SSL have helped in this situation?

No. SSL is security between a client and a server and the purpose of it is to prevent people in between from touching your data. In this case they are not intercepting any data, but using the iPhone API to get data that the iPhone app receives anyway.

Kudos to you for keeping this vulnerability secret and waiting for a fix. You've been waiting for a fix for almost three months, and without much of a response from the side of Tinder. And the latter I think is even more frustrating than the first.

Having been in a similar situation, I don't think I would have waited as long as you did.

I can't believe they don't do a simple fix that can be done in less than a minute. This is a serious information leaking issue. The time they spent on replying emails to the author are long enough for just get the fix done.

Funny, I was just pondering if this would work yesterday. Glad to hear that it's been mitigated to be less accurate.

I've always wondered if this could work, but I thought surely apps don't send the exact coordinates of a user.

https://www.apple.com/apps/find-my-friends/

That's a bit different; the very purpose of Find My Friends is explicitly to share your precise location with family/friends.

Really interesting - this exploit could apply to any social app that tells you the distance between you and another user

Yes and no. The degree of precision matters a lot. "between 3-4 miles away" isn't the same as "3.42123459921 miles away". In this case, the distance field was encoded in a 64 bit double - which if fully utilized is a ridiculous degree of unnecessary precision.

Yeah, deviantart had that problem at some point as well (if you gave deviantart your position).

To read, inspect <body> and disable {font-family: FontAwesome}.

Working on fixing this ASAP, what browser/OS are you using?

I found the content much more readable after chucking this in a console: document.getElementsByClassName('entry-content')[0].style.color='black'; and hitting <ctrl>+ a few times.

I believe it should be fixed now.

Fixed. Kudos to Erik on your team for emailing me to resolve immediately after my comment.

Hey Harlan, we think we fixed the FontAwesome problem, it was false advertising...the font was not awesome at all, it broke our whole damn blog.

It actually IS pretty awesome. You just generally don't want to apply it to the body of your entire site!

Anyone have a link to the previous vulnerability (from July 2013)?

Securing the channel with SSL should fix the issue, no?

No, as long as they send precise distance radius info, a person's location can easily be computed with very very small margin of error.

The easiest fix is just to send less precise location radius. The user does not care whether another user is 6 miles or 6.0000000001 miles away from him anyway.

The article states "By proxying iPhone requests...".

I don't see how the attacker can read the JSON payload if SSL is used. Am I missing something?

The attacker "is" the iPhone in this situation. The attacker creates his own requests and has the server talk to him in order to gain location info.

That doesn't seem to fix anything. Suppose you round to miles. Now I just sample the system until I find the "border" where the reported distance changes from 1 to 2 mile, and then I know the distance is exactly 1.5 mile there (or 2 miles if they round down).

Repeat for two more points and you have the same vulnerability.

You probably don't even need to go that far. The randomness will be reduced when using multiple locations for trilateration.

that's a good point. if the first guess point (60.000000N, 10.000000W) is a mile away from the wanted point. Then doing binary search on range say [60.001000N, 10.000000W] and [59.999000N, 10.000000W] will most likely to hit a boundary case (leap from 1 to 2 or 1 to 0). If not we then can make the search range a bit larger.

Rounding should work if you round the coordinates instead of the distance. Then you can at best calculate an approximate location very precisely.

SSL isn't hiding anything if the attacker controls the client endpoint :)

Uhm, no .. the app will still get the info. Why not just send "3" or "4" etc. for aprox distance?

What I don't understand is why the App needs the info, wouldn't it make more sense to change the API so it's just a call to /users?near={co-ord} and a simple list of users is returned without any location information? Sure you could still triangulate by using fake accounts and guestimating the boundaries based on when a user is and is not returned in the list…

EDIT: Ah, just fired up tinder, and saw the "x kilometres away from you" forgot about that haha :D

Reply on news.ycombinator.com