Subscribe Now

* You will receive the latest news and updates on the Canadian IT marketplace.

Trending News

Blog Post

Poké Lessons
SECURITY SHELF

Poké Lessons 

Game developers must be studying Pokémon GO as they contemplate future products. Here are some lessons learned from the game through the eyes of a security professional:

Privacy counts. Identifying information, such as a player’s name, age, and email address should not be required to play a mobile game. It is certainly desirable to allow the game to be restored or moved to a new mobile device, but this can be accomplished without providing an email address. If email is chosen as an account recovery mechanism it should be completely optional.

APIs will be accessed directly. Within days of being released, third parties wrote applications to map Pokémon locations. Cease and desist orders resulted. Application developers must not assume that only their game software will access server APIs.

Location is critical. Placing virtual objects at real geographic coordinates involves risk. Disclaimers and warnings may help reduce legal liability, but failing to act in a socially responsible way will always hurt the developer’s reputation. Players, especially children and teens, may not make appropriate decisions regarding private property and sensitive locations such as memorials. There is no shortage of businesses that would like to attract players to their vicinity. Game designers should consider an opt-in approach and ensure that property owners have a way to remove virtual objects.

Location information is sensitive. In games such as Pokémon GO, the player’s location is relevant to the game. If sending precise location information to the server is required, it should be used for game purposes only and discarded as soon as possible. Where possible, approximate locations should be used. For example, the game could send a lower precision latitude and longitude to the server and retrieve a list of precise object locations and an area map. Matching the player’s exact location to Pokémons and PokéStops could remain internal to the mobile device. Users should be clearly advised how location information is used and retained; burying it in the EULA or privacy policy is not good enough.

Network connectivity is not reliable. Pokémon GO’s design appears to assume a reliable connection to back-end servers. As a result, players in some areas encounter frustrating glitches. After throwing a ball at a Pokémon, the game may freeze, leaving the player wondering if it was caught or not. Clicking on a PokéStop sometimes results in a blank disk that will spin, not yield any objects, and yet the game refuses to allow the player to try again for five minutes. Levelling up usually results in an assortment of gifts, but sometimes they just don’t appear.

In a small coastal vacation town, I found many PokéStops within walking distance of each other and encountered many other players. But mediocre mobile phone coverage resulted in my phone regularly switching between AT&T and T-Mobile, 3G and LTE. While server load could be a factor, it appears that Pokémon GO is unable to recover from transient network outages during critical periods of play. As a result, players must terminate and restart the game, resulting in a sub-optimal experience. Mobile games should assume that Internet connectivity will be lost at the worst possible time and at least allow in-progress activities to complete normally.

Not everyone pays for data. Some people do not purchase mobile data service at all, and others forego it while travelling due to outrageous roaming costs. Hotspots and neighbourhood WiFi projects sometimes provide a viable alternative. Game developers should consider the possibility of caching local data to extend the playing experience between hotspots and reduce reliance on mobile phone carriers.

I asked Pokémon GO developer Niantic, Inc. about their use of GPS coordinates, constant Internet connectivity requirements, and more generally about the challenges of running such a large game infrastructure. They did not respond to my request for comment.

Have a security question you’d like answered in a future column? Email eric.jacksch@iticonline.ca

Related posts