Summary

  • El W3C publicó el primer borrador público de Geolocation el 22 de diciembre de 2008: una forma común de solicitar la posición del dispositivo sin imponer GPS ni otro método único.
  • La Recomendación del 24 de octubre de 2013 precisó las consultas puntuales, el seguimiento, la exactitud, el caché y el permiso expreso del usuario. La Segunda Edición de 2016 incorporó correcciones.

Una viajera sostiene el plano al revés. Una aplicación de mapas sabe dibujar una ruta hasta la parada del tranvía, pero primero necesita saber desde dónde empieza. La tentación es tratar la posición como otra casilla del formulario, tan inocente como el idioma de la página. La posición dice dónde está el dispositivo y, casi siempre, dónde está la persona. De ahí que el pequeño gesto de preguntar mereciera su propia arquitectura.

El primer borrador público del W3C, de 22 de diciembre de 2008, ofreció a los scripts una interfaz de alto nivel para la localización vinculada al dispositivo. Entre sus casos figuraban una visita que busca lugares interesantes en una ciudad extranjera y una persona que consulta su situación en un mapa. Las coordenadas, junto con una medida de exactitud, podían servir a ambas. La página no necesitaba convertirse en experta en antenas o satélites.

El borrador dejó abierta la fuente de la ubicación. Podía intervenir el GPS, la dirección IP, señales Wi-Fi, redes celulares u otros indicios. La web recibía un resultado normalizado, mientras navegador y dispositivo resolvían cómo obtenerlo. Ese reparto importaba: el mismo servicio podía funcionar en máquinas distintas sin prometer que todos los puntos azules nacían de un satélite. El dato de exactitud era una advertencia práctica para no confundir una zona probable con una baldosa exacta.

La interfaz distinguía un gesto de una vigilancia continuada. getCurrentPosition() solicitaba una posición; watchPosition() abría una serie de actualizaciones; clearWatch() detenía esa serie. Buscar una cafetería cercana y seguir un recorrido giro a giro son tareas diferentes. La versión de última llamada de 7 de julio de 2009 llevó esa mecánica y la discusión sobre privacidad a una fase posterior. El historial de publicaciones del W3C muestra que el camino desde la primera propuesta hasta la Recomendación de 2013 tomó años, no una tarde de entusiasmo cartográfico.

La Recomendación de 24 de octubre de 2013 dejó claro el mostrador de entrega. El agente de usuario no debía enviar una ubicación al sitio sin permiso expreso. En el navegador habitual, el diálogo de autorización debía identificar al host que preguntaba. Un permiso conservado más allá de la sesión tenía que poder revocarse. Si la persona decía que no, la llamada terminaba con PERMISSION_DENIED. El sitio podía pedir el punto azul; el navegador no lo entregaba como propina.

Había otras decisiones en la propia consulta. maximumAge permitía aceptar una posición guardada, quizá suficiente para mostrar el tiempo de la ciudad. timeout limitaba cuánto se esperaba por un nuevo cálculo. enableHighAccuracy pedía un resultado mejor, con posibles costes de tiempo y batería, aunque sin garantía de conseguirlo. El reloj de timeout no contaba el tiempo dedicado a pedir permiso a la persona. Hasta una aplicación impaciente debía aguardar mientras su usuario leía la pregunta.

La respuesta incluía latitud, longitud y accuracy en metros. Según el texto de 2013, las cifras de exactitud debían corresponder a un nivel de confianza del 95 %. Más que un alfiler clavado en el zapato de la viajera, el resultado podía dibujar un círculo alrededor de su situación probable. La Recomendación tampoco garantizaba la posición real del dispositivo. Un mapa sensato puede orientar incluso cuando reconoce la amplitud de su propia duda.

Obtener una respuesta tampoco convertía todos los usos posteriores en parte de la misma petición. El W3C pidió a los receptores solicitar la ubicación cuando hiciera falta, emplearla para la tarea indicada, desecharla al terminar salvo autorización expresa para guardarla y no retransmitirla sin permiso. Una búsqueda de tranvías y un archivo de movimientos empiezan con dos números idénticos. Son contratos distintos con la viajera.

La Segunda Edición de 2016 incorporó correcciones a la Recomendación de 2013. Conservó el reparto esencial: navegador y dispositivo estimaban, la persona autorizaba la entrega, y el servicio decidía cómo usar un dato recibido legítimamente. La API fue útil precisamente porque no ordenó que todas las páginas emplearan el mismo mapa, el mismo sensor o la misma duración del seguimiento.

Ese es el cambio histórico. La web encontró una manera común de conectar scripts con la calle real sin convertir cada petición en un derecho automático a conocer al visitante. Nuestra viajera quizá siga leyendo mal el plano. Al menos, el navegador aprendió a preguntar antes de señalarla.