W3C Geofencing API Spec Ready for Comment & Contribution

A draft API specification has been released by the World Wide Web Consortium (W3C) to promote standardization in designing Geofencing APIs.

Geofencing refers to the setting up of geographical boundaries and then monitoring them to determine when an application user’s device enters into each defined geofence boundary.

While often touted as a way to do proximity marketing, the use cases for geofencing are actually much wider and more useful than contextual advertising, which could feel intrusive, still not be relevant to a customer’s needs, and quickly become overbearing if there are too many geofenced locations a user might potentially walk through.

More interesting use cases could include, for example, customer service delivery applications, where support requests could use geofencing to identify and connect with local repair contractors to automatically book appointments for a customer at the nearest repair site.

In health care, geofencing could help identify when patients with dementia wander outside of care facilities. In logistics, moving companies and freight transport could use geofencing to provide realtime alerts to traffic-avoidance issues based on the driver’s chosen route. Warehouse and ports transport could better manage staff resources if able to use geofencing to identify when trucks enter loading docks. In construction, geofencing could ensure that machinery is operating in set places within a site. Other ideas abound.

Many of these use cases could leverage APIs to become machine-to-machine in nature as the Internet of Things (IoT) trajectory increases. Already, smart vending machines can issue their own repair requests to local contractors. Geofencing APIs could be used to create a more efficient repair rostering schedule that reduces fuel costs by better identifying which contractor is closest to the machine needing to be repaired.

The W3C Geofencing API is a spinoff of the Geolocation API. While that API specification suggests standards for how an app creates endpoints and manages API requests to check the current geographic position of an application user’s device, the geofencing API is considered to be a more powerful and efficient approach.

A key reason for this is that the spec makes use of a new object approach similar to Webhooks called Service Workers. (A GitHub website by Jake Archibald looks at the rollout of Service Worker tech in common internet browsers.) Service Workers, for example, can pull geographic information first, and then decide what information to render on a webpage based on this data.

The Service Worker approach is now also being proposed in the Geofencing API.

One of the impacts this will have is that an application can continue to collect an application user’s device location even if they have exited and closed down their app.

The W3C draft spec page shows code examples for 4 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

Given the privacy concerns that geofencing raise, the draft spec affirms that best-practice privacy approaches need to be thought through in greater depth, with — at a minimum — the geofencing app meeting similar standards around location privacy as the Geolocation API spec.

Electronic Frontier Foundation Senior Staff Attorney Lee Tien reviewed the Geofencing API and is not too worried about the implications at present. He told ProgrammableWeb:

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.

The Geofencing API still has several issues that require community input, including defining geofencing zones consistently, validity checking, and defining error attributes. A mailing list and list of open issues on GitHub is available so that developers can contribute. 

Be sure to read the next Standards article: ​SmartBear, Linux Foundation launch Open API Initiative to Evolve Swagger