Hacker News Reader

There is no better case study for this than Pokemon Go, where the interest in spoofing location reached unheard of levels (outside of state actors). This is a good writeup:

http://engineering.shapesecurity.com/2016/08/pokemon-go-api....

Basically sign your API requests with the most obscure function of phone context variables imaginable, and recognize that if you get so popular that it's cracked, you can just hire a machine learning team anyways. And pin your certs!

Before Pokemon Go there was Ingress and hoo boy was/is this a problem.

Swarm/Foursquare I believe solve this problem by tracking the time between check-ins and then consider the distance between the places you've checked into and how long it would take to travel between them. You can't check into a store in New York Times Square one minute and then the next minute check into a place in Los Angeles. Sure you can lie, but with this restriction and restrictions around how frequently you can check in and other levers they have made a high quality experience that works for what they want to do.

IIRC credit card companies do a similar thing to reduce fraud

Ping the clients and average out data from clients near the lat/long sent with the request and compare to the client in question.

Apply a max threshold to check if a client is reasonably close to potential "co-located" clients.

You can't shrink physical distance. Pinging a server in a nearby US city is 13ms. Hong Kong is 232ms.

Even if you could fingerprint the location accurately, how do you know I'm there now, vs. capturing all of the information when I was there and replaying them later?

A much easier problem than "are you really where you say you are?" is "are you likely to be sending me fake locations?", which is hard to do with a single location update, but if the user is moving rapidly, or in geographically distant locations across multiple updates it's much easier to catch.

This is something that I'm currently dealing with as well. However, I'm a little less concerned with trusting the location in particular and more in whether or not the client itself is trustworthy.

Do you have a user login system? Can you easily isolate fake data to a certain set of accounts? Or are you dealing with anonymous requests?

One possible solution you can look into is signature authentication of the headers to verify that the request is coming from a trusted source. You can either us a public/private key pair or a symmetric key with HMAC. That being said, this isn't foolproof - you have to keep the key secure, and that isn't totally possible in an app. If someone attaches a debugger they will be able to get your secret key if they're determined enough. The best you can do is obfuscate / encrypt the key so that it can't easily be read out from the strings in your app.

If you wanted to verify the location data itself, you could look into modeling the user's movements and look for abnormalities in the sequence of locations. Also, you can check the location against an API like Google or Foursquare on the back end.

Curious to hear what other people think as well.

Send temperature and barometric pressure. Temp will vary (inside/outside) but pressure should be reasonably consistent.

How is that any more trustworthy? You can probably use the same source the server would use to verify that information.

Not to mention, most phones may not have those sensors.

Some very popular phones have a barometer[1]. If you are getting data from a bunch of phones, and most of them are legit, then you'll have a good idea of where the air pressure 'should' be, and if you get a barometer reading that is outside that data set by a standard deviation you can probably 'guess' that it is not coming from a phone at the same lat/lon as the other ones.

[1] https://www.phonegg.com/list/303-Cell-Phones-with-Barometer

So users on phones without barometers cannot use your app, and you are decidedly mobile-only, forever.

Not at all, the question was how to combat or at least estimate fraudulent 'adjustment' of the karma in a location based service. The way to do that is to take information that is specific to the location, and changes, and provide that data in the input stream to help understand where your clicks/votes are coming from. If one in 5 phones has a barometer with a high degree of probability, then you can use set bounds on the likelyhood that all 5 votes came from legitimate users. It won't be perfect but it will make it harder for scammers to scam without being there.

This is a really clever idea. Do you have sources of information about what sensors are present in which phones?

That only adds one extra step to spoofing - now I have to check weather.com for the barometer reading in the location I plan to poof before sending. NBD...

Also, pressure in vs outside can vary more than you'd think...

As with anything, it can be over come at a cost, and the only thing anyone can hope for is to keep the cost of defrauding a system higher than the expected return of successfully defrauding it.

Phone temperature is completely useless if the device is kept in a pocket next to human body temperature. Phones are also self-heating, especially when running Pokemon Go.

Barometers aren't very widely spread and I'd be wary of their calibration.

https://www.locationsmart.com provides a service to locate devices at the cell tower level. You can use it to verify location updates from the device are in the ballpark of where they say they are. I haven't used it personally but a friend did.

Looks like they just do a HLR lookup to get cellphone location, which at worst gives you the cell tower location and sector the phone is connected to.

you could maybe just trust them but flag/disable accounts that jump between locations extremely quickly.

Might be tricky accounting for air travel but even then you could safely assume nobody's taking more than two flights a day and six a week or something like that

Yep, trusting every submission initially is fine, and we do use tricks like you suggest to flag suspicious accounts. For instance if you submit "11111" then "11112" then "11113" on up through "99999" (I've seen it happen!) then we might disqualify you from the raffle. :-) (We have better heuristics than that too.) But having the phone send some kind of extra proof would still be helpful. To point is just to make location spoofing "hard enough," not impossible. Also it is a small enough event that fraud isn't a true problem right now, so this is more just a fun mental exercise for me at this point. Still, good to be prepared!

I think the reason that API is private is because people do not want that level of tracking. And there are very few applications which absolutely, positively need this level of accuracy. And, I'm sorry, but marketing/advertising doesn't count.

In my case it is: the store gives you a secret code, and you enter it on your phone to earn discounts and raffle entries. We would like to prevent people taking the code home and sharing it with all their friends. So it's not about tracking. Still I get why the restriction needs to be there.

Make them have to submit it via a WIFI network in the store?

Or arrange some kind of (perhaps NFC based) token signing system.

QR codes. Show them on a screen to invalidate them every time they're used.

Why don't you make a unique code for each user?

If you have a mobile application, you can use that + beacon based location, so the code can be used only inside a store.

Can you ask them?

Make the user take a pic of the store, then check the EXIF for the timestamp. The pic should be very easy to shape-compare with other submissions of the same store (hardware doesn't move much, as opposed to faces), and the pic should never be exactly the same (refuse submitting twice the same pic).

Other solutions require the participation of the store: Dynamic QR codes, microphone authorization, or a website on the store's Wifi internal network.