There are a number of popular services which have some idea of publishing your location, either automatically or on demand, often called checking in. Increasingly the companies who run these services, such as foursquare, are partnering with businesses to provide offers to customers who check in at their shops or restaurants. As this becomes more popular it increases the financial incentive to fake location and game the system. Technically, this is essentially trivial, since the service takes the phone “on its word” about its current location, which can easily be spoofed, especially where the service offers an api for 3rd party clients to write against. This got me thinking, it would be useful if there was a method of verifying location which could be required to benefit from location based offers etc. Thinking about the problem, an obvious step to take is to make the act of checking in require some answer to a question which you would only know if you were present - how many tables are there? What is the duty managers name? Such questions have problems of course, the answers need to be relatively unguessable for those not present, and need to change frequently enough that one cannot continue to check in having visited once. Along with this second requirement comes a complexity for the place being checked in to - if the question and answer are changing, they need a mechanism to update the checkin service with this information. If we boil down our requirements, what we are really looking for is a number or code which people present in the building would be able to see, changes frequently, and which the checkin service providers would also know. fortunately we already have such a system - hardware authentication tokens.
Hardware authentication tokens contain some secret, known by the manufacturer / provider, which it hashes together with a changing value, usually time or counter based to provide a changing psudo random value, generally displayed on an lcd screen. This code is hard to guess yet easily verified by the provider as they too are party to the tokens secret. These authentication tokens are usually used as part of a multi-factor log in, representing the “something you have” generally coupled with the “something you know” factor of a password. However, if the token is secured in place rather than carried with you, it now changes to providing “somewhere you are” or more precisely “something you can see”.
Some system could be created where tokens with large displays are embedded in a sign, saying something like “Foursquare verified check in” and affixed in a visible location inside the premises, perhaps just above the door on the inside. This then provides a way for the check in service to provide a higher level “verified” check-in for locations and customers who care to use it. Users would merely enter the few digits currently displayed on the sign into the app they are checking in with.
Such a system would make it more practical for organisations to use a users check in for more sensitive purposes, such as giving discounts for regular check ins. Perhaps more interestingly though, having this increased confidence that a users is physically present would allow a location to offer new services which only make sense for people actually there. For example a restaurant could provide a site at which people could order food to their table from their phones. If such a service was made available to anyone online its easy to see the problems which it could cause. On the other hand, if the site requested a code, displayed on a token affixed to the table, it could verify that the visitor was not only at the restaurant, but at the table to which they were ordering food. A similar example might be to allow customers in a coffee shop to place their orders on a mobile site while in the queue, meaning their coffee can be prepared while they wait to pay. Perhaps more generally you could see that any service which could otherwise be offered by placing kiosks in a location could be provided through such a website using verified location, but without the space and costs requirements.
Software Engineer with over 12 years experience shipping solutions in node.js, Typescript, Elixir, C#, and C++