Summary

  • Le 22 décembre 2008, le W3C a publié une première ébauche d'API donnant aux scripts accès à une position liée à l'appareil, sans imposer GPS, réseau mobile ou autre méthode de calcul.
  • La recommandation du 24 octobre 2013 a établi la demande unique, le suivi continu, une indication de précision, la réutilisation d'une position en cache et l'autorisation expresse de la personne. Une seconde édition de 2016 a corrigé le texte.

Une touriste cherche le tramway. Elle a un plan, un nom de rue prononcé de travers et la certitude que la rivière se trouve au mauvais endroit. Une carte sur le Web pourrait dessiner un point bleu et sauver l'après-midi. Encore faut-il que le site sache où placer ce point. Demander cette information n'a rien d'anodin : « près de la gare » et « devant cette porte, maintenant » ne sont pas le même renseignement.

Le premier projet public du W3C, daté du 22 décembre 2008, proposait une interface de haut niveau pour obtenir la localisation de l'appareil qui héberge le navigateur. Ses cas d'usage parlaient déjà de visiteurs cherchant des lieux intéressants dans une ville étrangère et de personnes consultant leur position sur une carte. L'interface fournissait une latitude, une longitude et une précision ; elle ne promettait pas que le site connaîtrait magiquement une adresse postale.

Le texte se gardait de sacrer un fournisseur de position. GPS, adresse IP, signaux Wi-Fi ou cellulaires pouvaient contribuer au résultat. Le navigateur et l'appareil faisaient le travail de localisation ; la page recevait un résultat dans un format commun. La valeur de cette abstraction est facile à oublier. Un guide de quartier ne devrait pas devoir écrire une version pour chaque antenne, puce et réseau. Il lui faut une position utile et une mesure de son incertitude.

Le projet distinguait deux rythmes. getCurrentPosition() servait à obtenir une position une fois, par exemple pour centrer une carte. watchPosition() suivait les changements, utile à un itinéraire qui continue pendant le trajet ; clearWatch() arrêtait cette surveillance. La différence est concrète : indiquer le musée le plus proche n'autorise pas à suivre chaque détour de la touriste jusqu'au dîner. La version du 7 juillet 2009 porta ces mécanismes et les questions de vie privée plus loin dans l'examen du W3C.

La recommandation du 24 octobre 2013 plaça l'autorisation au cœur du passage. Le navigateur ne devait pas envoyer la localisation à un site sans l'accord exprès de la personne. Dans le navigateur ordinaire, l'interface de permission devait montrer l'hôte demandeur. Une autorisation conservée au-delà de la session devait pouvoir être retirée. Un refus produisait l'erreur PERMISSION_DENIED, pas un assentiment silencieux. La carte pouvait poser la question ; elle ne recevait pas la réponse par droit de curiosité.

Les options rendaient la demande moins grossière. maximumAge indiquait si un résultat conservé en cache pouvait suffire. timeout limitait la recherche d'une nouvelle position. enableHighAccuracy exprimait un souhait de meilleure précision, avec le coût possible d'une attente plus longue ou d'une consommation d'énergie accrue. Ce n'était ni une garantie ni un ordre donné au GPS. Le temps que prend une personne pour accepter ou refuser ne comptait d'ailleurs pas dans le délai d'acquisition. Même une machine pressée devait laisser au voyageur le temps de lire le panneau.

Le résultat comportait un champ accuracy exprimé en mètres. Le W3C indiquait que les valeurs de précision devraient correspondre à un niveau de confiance de 95 %. Le fameux point bleu ressemble donc davantage à un cercle de possibilités qu'à une épingle plantée au millimètre. La recommandation précisait aussi qu'aucune garantie ne portait sur la position réelle de l'appareil. Une carte honnête pouvait aider à trouver la rue sans prétendre connaître la dalle exacte sous les pieds de sa lectrice.

L'accord initial ne réglait pas tout ce qui suit. Le texte de 2013 demandait aux destinataires de solliciter la position lorsque c'était nécessaire, de l'utiliser pour la tâche annoncée, de l'effacer une fois cette tâche terminée sauf accord exprès pour la garder, et de ne pas la retransmettre sans consentement. Une recherche de station de tramway et la constitution d'un carnet permanent de déplacements peuvent partir des mêmes coordonnées. Ce sont deux opérations différentes.

Le calendrier de publication montre le trajet de l'ébauche 2008 à la recommandation 2013. La seconde édition de 2016 a incorporé des corrections au texte de 2013. L'essentiel tenait déjà dans ce petit comptoir : le site demandait, le navigateur trouvait une estimation, la personne décidait du premier partage. Ensuite, l'application devait répondre de ce qu'elle faisait du renseignement reçu.

Ce n'est pas qu'une histoire de cartes. Météo locale, recherche de lieux proches et itinéraires avaient besoin d'une même grammaire sans avoir le même besoin de précision ou de durée. L'API leur donna cette grammaire. La touriste pouvait encore se tromper de rive ; au moins, son navigateur avait appris à demander avant de la corriger.