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.
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.