Summary

  • W3C's first public Geolocation API draft appeared on 22 December 2008, defining a browser-mediated way for scripts to request the hosting device's position without prescribing whether GPS, network signals or another source found it.
  • The 24 October 2013 Recommendation made one-shot requests, ongoing watches, accuracy, cached positions and express user permission part of the interface. A 2016 Second Edition incorporated corrections to that Recommendation.

The tourist turns a street map upside down and discovers that the river has moved to the wrong side of town. A nearby web map could end the argument in a second, provided it knows where to put the tourist. That is a rather personal fact to ask for over a browser window. The surprise in the early Geolocation API was not that a device might know roughly where it was. It was that a website gained a standard way to ask, and the browser stood at the counter between the request and the answer.

The first public W3C Working Draft, dated 22 December 2008, described a high-level interface for location associated with the device hosting the browser. Its examples included a visitor searching for points of interest in a foreign city and a traveler finding a position on a map. These are ordinary needs with a sharp edge: a café search needs a neighborhood, while a turn-by-turn route may keep asking where the traveler has gone. The draft offered both a single position request and updates as position changed.

It did not appoint GPS king of the street. The interface was agnostic about how a position was found. The draft named satellite positioning and network clues such as IP address, Wi-Fi, Bluetooth and mobile-cell information among possible sources. The site received coordinates and an accuracy value, not a certificate saying a particular radio or satellite had solved the case. The browser and device could decide how to find a useful answer. A dot on the map was a claim with a margin, not a tiny person pinned to a mathematically perfect spot.

This distinction mattered for the software built above it. getCurrentPosition() asked once. watchPosition() let an application receive later updates, and clearWatch() stopped that watch. The 2008 draft already made the difference intelligible: finding a nearby museum is not the same job as following a journey through the city. The 7 July 2009 Last Call Working Draft carried the interface and its privacy questions further through W3C review. The publication history shows the long road from that 2008 opening through the 2009 draft to a 2013 Recommendation.

The 24 October 2013 Recommendation spelled out the handoff. The browser's user agent could not send location information to a website without the person's express permission. In the normal browser case, the permission interface named the requesting host. A permission carried beyond the current session had to be revocable. Refusal produced a PERMISSION_DENIED error rather than a hidden success. That gave the tourist a real choice at the counter before the map received the dot.

The same document separated the act of asking from the mechanics of finding. PositionOptions allowed an application to indicate enableHighAccuracy, set a timeout, and say how old a cached result could be through maximumAge. Higher accuracy was a hint, not a promise; the browser might take longer or use more power, and the device might have no better fix available. A cached position could be useful to a weather page but awkward for a person who had crossed town. A timeout applied to finding the location, not to the seconds a human spent considering permission. The standard refused to put a stopwatch on the tourist's decision.

The returned position had latitude, longitude and an accuracy figure measured in meters. The Recommendation said the accuracy values should correspond to a 95 percent confidence level. The map therefore had grounds to draw a circle around the dot rather than act as if it had discovered the traveler sitting on one precise paving stone. The document also said the API offered no guarantee of the device's actual location. Coordinates were useful evidence for a service, with a stated limit on how finely the service should read them.

Receiving the coordinates did not make every further use the site's business. The 2013 text instructed recipients to request location when needed, use it for the task offered, dispose of it when the task ended unless retention was expressly permitted, and avoid retransmitting it without express permission. These are practical distinctions. A map finding a tram stop and a site building a permanent travel diary can begin with the same pair of numbers. The first request should not smuggle in the second job.

The 2016 Second Edition incorporated corrections to the 2013 Recommendation. It was another step in maintaining the original bargain, not a sudden discovery that maps exist. By then the useful dividing line was familiar: the browser provided a common question and guarded the answer; the application chose what to do with a coordinate it legitimately received. The traveler could ask for directions without handing every shop on the street a copy of the itinerary.

That is why the location prompt belongs in the history of the web rather than a footnote to a mapping product. A small browser interface connected the messy physical world to scripts: coordinates, accuracy, one request or a watch, and a person who could decline. The tourist may still hold the map upside down. At least the browser learned to ask before correcting her.