Polyglot Technologist. Random Thoughts on Software and Computing, Tech and Science.

TwitterLinkedIngithubPublicationsAbout

Written in

by


We are seeing increased use of location data in mobility solutions such as mobile social software and in employee tracking solutions. And it is important to remind ourselves, the mobility developers, product managers and people in general, responsible for the creation of location-based services/software (LBS) and applications, about the responsibilities that come with such kind of software and solutions and the implications on privacy. And these responsibilities can be summarized in three words: Do no Evil.

Location-based applications can bring many benefits to business processes, and help create exciting social and business software, but poorly used or mismanaged, especially when applied to people or personal information, can become a major area of concern with respect to privacy.

As a result of working on LBS and understanding not only the power of LBS but its dangers, privacy-related issues, and the responsibilities that we (should) have as creators of such software, such concerns prompted me to define a set of Guidelines for LBS Developers that I originally published on my website many years ago and that should continued to be evangelized in hopes of helping educate new developers, product managers, and product marketing about this important topic. The use of location/geo-positioning information in software will continue, and the key is to understand the implications and be responsible with its such data use.

The Guidelines

When designing and developing location-based software, let's keep in mind the basic rules of privacy. The following guidelines were written to help create privacy-conscious applications:

  • Always Alert the User:
    • Show a privacy notice – The user must be notified that the application collects, records and transmits personal (location) information.
    • This privacy notice must be properly localized (i.e. right language for the particular country) and must be explicit.
    • This privacy notice must be displayed and acknowledged, at least once (probably the first time the application is used). This acknowledgement must be recorded. Note that recording the acknowledgement also serves to protect you, validating you did your part notifying the user.
    • This privacy notice should be re-displayed every once in a while, lets say once a month, or once a quarter, or something that is configurable, but the notice should never be disabled.
  • The End-User, the Ultimate Decision Maker:
    • The application must provide the means to turn off location tracking at ANY time. Always give the device-user the ultimate decision for being tracked or not, for using geo-location information or not!
  • Safeguard All Captured Information:
    • Location information and ALL personal information, if stored on the device, must be safeguarded: 1) not accessible by other programs or entities, 2) and possibly encrypted.
    • Location information and all personal information, if transmitted, must be properly encrypted.
    • And if stored on the server, must be totally safeguarded (access-control, encrypted).
  • Use Geofecing responsibly | Use Passive Tracking instead
    • Geofencing can be a scary thing. Don’t use geofencing to track others, instead use passive tracking.
    • Geofencing though has its benefits when given as an option for a user to apply it to *him/herself*;for example for reminders related to places such as reminders when entering the grocery store.
  • Be responsible and Do no Evil with the captured data.

When creating location-based software, you may not intend do to any evil, but inadvertently you may enable (someone else to do) evil – the above guidelines are a good start to minimize those concerns. In addition, make sure everyone in the project, from marketing to development, to the customer themselves, understand these (privacy) concerns. Give the power to the end-user, and protect the end-user, and the collected data. Again, do no evil, as Google says.

If you have any other suggestions, please feel to add a comment and feel free to disseminate these guidelines.

Related to this see:
* Security & Privacy on Mobile Apps, Part 1 – Introduction
* Security & Privacy on Mobile Apps, Part 2 – Typical Security Elements of a Mobile Application
* Security & Privacy on Mobile Apps, Part 3 – PCI Compliance

ceo

—-
Originally written on December 21, 2004.
Revised on July 15, 2005.
Revised on Aug 6, 2010.
Revised on Dec 7, 2013 – added “related security & privacy on mobile” references.