6 ms·

A problem I've mused on for a few years is related to this: when a phone submits a lonlat to an API server, how can you make the server more confident it can tr

A problem I've mused on for a few years is related to this: when a phone submits a lonlat to an API server, how can you make the server more confident it can trust the location? I mean with curl I could POST any lonlat I want---I don't even need a phone! I don't think this is truly solvable, but how can you make spoofing the location harder? The scale I'm thinking about is "Are you really in the store you say you're in?" where all users are from the same fairly dense city. So geolocating the IP isn't good enough. Accuracy to a city block or two seems good enough though. My best idea so far is to submit a list of available wifi access points, and use that as a "password" to prove that you're where you say you are. If your list is 80% like the list of other users at that location, we trust you. Unfortunately in iOS you can't get that list! It requires a private API, so calling that method will get your app rejected from the store. Does anyone have any other ideas?

s73ver 10y ago
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.
- pjungwir 10y ago
  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.
  - nso 10y ago
    Make them have to submit it via a WIFI network in the store?
    - Crespyl 10y ago
      Or arrange some kind of (perhaps NFC based) token signing system.
  - tajen 10y ago
    QR codes. Show them on a screen to invalidate them every time they're used.
  - misingnoglic 10y ago
    Why don't you make a unique code for each user?
  - piokoch 10y ago
    If you have a mobile application, you can use that + beacon based location, so the code can be used only inside a store.
ChuckMcM 10y ago
Send temperature and barometric pressure. Temp will vary (inside/outside) but pressure should be reasonably consistent.
- itake 10y ago
  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.
  - ChuckMcM 10y ago
    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 https://www.phonegg.com/list/303-Cell-Phones-with-Barometer
    - komali2 10y ago
      So users on phones without barometers cannot use your app, and you are decidedly mobile-only, forever.
      - ChuckMcM 10y ago
        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.
coderholic 10y ago
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.
evan_ 10y ago
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
- pjungwir 10y ago
  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!
mevile 10y ago
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.
- jfktrey 10y ago
  IIRC credit card companies do a similar thing to reduce fraud
tajen 10y ago
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.
btown 10y ago
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.html 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!
- memmcgee 10y ago
  Before Pokemon Go there was Ingress and hoo boy was/is this a problem.
briankzimmer 10y ago
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.
lspears 10y ago
https://www.locationsmart.com 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.
- posguy 10y ago
  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.
halisaurus 10y ago
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.

s73ver 10y ago

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.

pjungwir 10y ago
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.
- nso 10y ago
  Make them have to submit it via a WIFI network in the store?
  - Crespyl 10y ago
    Or arrange some kind of (perhaps NFC based) token signing system.
- tajen 10y ago
  QR codes. Show them on a screen to invalidate them every time they're used.
- misingnoglic 10y ago
  Why don't you make a unique code for each user?
- piokoch 10y ago
  If you have a mobile application, you can use that + beacon based location, so the code can be used only inside a store.

ChuckMcM 10y ago

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

itake 10y ago
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.
- ChuckMcM 10y ago
  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 https://www.phonegg.com/list/303-Cell-Phones-with-Barometer
  - komali2 10y ago
    So users on phones without barometers cannot use your app, and you are decidedly mobile-only, forever.
    - ChuckMcM 10y ago
      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.

coderholic 10y ago

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.

evan_ 10y ago

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

pjungwir 10y ago
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!

mevile 10y ago

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.

jfktrey 10y ago
IIRC credit card companies do a similar thing to reduce fraud

tajen 10y ago

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.

btown 10y ago

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

memmcgee 10y ago
Before Pokemon Go there was Ingress and hoo boy was/is this a problem.

briankzimmer 10y ago

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.

lspears 10y ago

https://www.locationsmart.com 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.

posguy 10y ago
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.

halisaurus 10y ago

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.