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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
"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.
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:
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.
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.
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.
[+] [-] discostrings|12 years ago|reply
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.
[+] [-] doktrin|12 years ago|reply
Not taking trilateration into account may have been a careless mistake. Sending literal GPS coordinates, however, means the developer probably didn't care.
[+] [-] auston|12 years ago|reply
[+] [-] CompleteMoron2|12 years ago|reply
[deleted]
[+] [-] herbig|12 years ago|reply
Once you've found their Twitter/Instagram/whatever, then you have a name. Now you have their Facebook profile.
[+] [-] glenda|12 years ago|reply
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.
[+] [-] modo_|12 years ago|reply
[+] [-] sumnulu|12 years ago|reply
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
[+] [-] erichocean|12 years ago|reply
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.
[+] [-] elwell|12 years ago|reply
[+] [-] IncludeSecurity|12 years ago|reply
[+] [-] midas007|12 years ago|reply
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.
[+] [-] supercoder|12 years ago|reply
[+] [-] Skrypt|12 years ago|reply
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.
[+] [-] 1timecomment|12 years ago|reply
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.
[+] [-] NamTaf|12 years ago|reply
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.
[+] [-] philip1209|12 years ago|reply
[+] [-] doktrin|12 years ago|reply
[+] [-] mLewisLogic|12 years ago|reply
[+] [-] tyho|12 years ago|reply
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.
[+] [-] natdempk|12 years ago|reply
[+] [-] dmur|12 years ago|reply
"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.
[+] [-] IncludeSecurity|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] tmsh|12 years ago|reply
https://github.com/tmsh/guess-city-on-radius
[+] [-] Cthulhu_|12 years ago|reply
[+] [-] mikeleeorg|12 years ago|reply
[+] [-] Johnie|12 years ago|reply
[+] [-] cooper12|12 years ago|reply
[+] [-] jvdh|12 years ago|reply
Having been in a similar situation, I don't think I would have waited as long as you did.
[+] [-] jw2013|12 years ago|reply
[+] [-] foldor|12 years ago|reply
[+] [-] Nicholas_C|12 years ago|reply
[+] [-] erichocean|12 years ago|reply
[+] [-] squigs25|12 years ago|reply
[+] [-] doktrin|12 years ago|reply
[+] [-] panzi|12 years ago|reply