Geofencing refers to the practice of using or creating a virtual perimeter that applies to a real-world geographic area. In terms of digital technology, geofencing can be used to control where objects are, and are not, allowed to go. For example, geofencing might be used to track packages that that are to be delivered along a particular route. It could be used to verify that rented vehicles are not transgressing a predetermined boundary. It could even be used in healthcare to ensure that patients with dementia do not accidentally leave the premises of their healthcare facility. It could be used to establish a perimeter within which a drone may be flown or landed.
Needless to say, geofencing has many potential applications in a broad spectrum of fields. It doesn’t take too much imagination to see the cost-saving potential (not to mention the increased utility) of geofencing applications being able to talk to each other. If there were an open standard that geofencing applications used, then intercooperation between applications could increase the reach of both without requiring either to expand their own infrastructure.
The World Wide Web Consortium (W3C) has released a draft API (application programming interface) specification that is intended to promote standardization and interoperability in Geofencing. This draft is itself based on W3C’s own Geolocation API, a specification for applications that allows the user to check the current geographic location of his or her device. The Geofencing API is considered an improvement on the Geolocation API because it utilizes an object approach called Service Workers which can pull pertinent geographic information and then decide what information to render on a webpage for user consumption.
One effect that the Service Worker approach will have on the Geofencing API is that applications that use the API can continue to collect a user’s geographic location even after the application has been closed. Not surprisingly, features such as this do raise privacy concerns. In response, the W3C’s draft is going to great lengths to outline best-practice approaches for privacy. At present, the W3C draft shows four examples of common call requests in geofencing:
- Monitor a region
- Respond to a region being entered
- Respond to an error condition
- Unmonitor a region in response to some other event
Electronic Frontier Foundation Senior Staff Attorney Lee Tien responded to the privacy concerns that the Geofencing API represents:
This isn’t terrible, but it is very bound to consent, and that’s a weakness since
(a) it is not common knowledge about how sensitive location data actually is and what can be done with it — a person might say “oh, it’s OK because my identity is anonymous” — but not realize that the location data itself can pierce anonymity (e.g., location data on Lee Tien (even if masked as X) shows that X spends days at 815 Eddy and nights at my house in Berkeley, so who else could X be?)
(b) users give consent to get things done and often without understanding the sensitivity of location data or even what the deal they agreed to entails
(c) there’s no obvious consideration of location granularity or fuzzing.
But these are technical standards and one of the big issues in the technical standards world is the extent to which policy standards are to be built into them. It is inevitable but as the geolocation API spec says, inherently difficult.
If you are interested in contributing to the development of the Geofencing API, there are a few ways to get involved. You can sign up to be on the project mailing list in order to get the latest information about the API, and you can view a list of open issues on GitHub. As always, we encourage you to leave your thoughts in the comment section.