Summary

  • O W3C publicou o primeiro rascunho público da Geolocation API em 22 de dezembro de 2008, propondo uma maneira comum de pedir a posição do dispositivo sem impor GPS ou outra fonte única.
  • A Recomendação de 24 de outubro de 2013 definiu pedidos únicos, acompanhamento contínuo, precisão, cache e autorização expressa; a Segunda Edição de 2016 incorporou correções ao texto.

Uma viajante procura o ponto do bonde. O mapa de papel está de cabeça para baixo, o nome da rua parece familiar e o rio insiste em ficar do lado errado. Uma página de mapas poderia colocar um ponto azul e resolver a questão. Para isso, precisa receber coordenadas. O mesmo dado que encontra a parada também revela por onde uma pessoa anda. A Geolocation API tratou a entrega como uma ação, não como um presente automático a qualquer página curiosa.

O primeiro rascunho público do W3C, de 22 de dezembro de 2008, desenhou uma interface de alto nível para a localização associada ao aparelho que hospeda o navegador. Seus exemplos incluíam gente em uma cidade estrangeira procurando lugares próximos e uma pessoa localizando-se num mapa. A página receberia latitude, longitude e indicação de precisão. Não precisaria perguntar qual fabricante havia colocado um receptor no bolso da viajante.

A proposta deixou a origem do cálculo em aberto. GPS era uma possibilidade; endereço IP, Wi-Fi, Bluetooth e rede celular também podiam fornecer pistas. Essa liberdade permitia a dispositivos diferentes responder à mesma pergunta. Também impunha modéstia ao mapa: um ponto não é a certidão de que alguém está exatamente sobre determinada pedra da calçada. A precisão faz parte da resposta porque localização estimada tem margem.

Havia duas maneiras de perguntar. getCurrentPosition() solicitava uma posição uma vez. watchPosition() abria uma série de atualizações, e clearWatch() encerrava esse acompanhamento. Encontrar um café perto dali é um trabalho curto. Guiar a pessoa por várias ruas, acompanhando suas mudanças de posição, é outro. O rascunho de Última Chamada de 7 de julho de 2009 levou essas escolhas e as questões de privacidade mais longe. O histórico de publicação do W3C mostra o intervalo entre o início de 2008 e a Recomendação de 2013.

A Recomendação de 24 de outubro de 2013 deixou claro quem abria a porta. O navegador não podia enviar a localização a um site sem permissão expressa da pessoa. Na situação comum do browser, a interface de autorização mostrava o nome do host que pedia os dados. Uma permissão preservada além da sessão precisava ser revogável. Se a resposta fosse não, a aplicação receberia PERMISSION_DENIED. O pedido do mapa não virava uma autorização por insistência.

As opções permitiam calibrar o pedido. maximumAge dizia se uma posição guardada em cache ainda servia. timeout limitava a espera pela aquisição. enableHighAccuracy sinalizava o desejo por melhor precisão, possivelmente com mais tempo ou consumo de energia, sem prometer o resultado. O tempo que uma pessoa levava para decidir sobre o pedido não entrava no cronômetro da aquisição. Até um mapa apressado tinha de esperar a viajante ler a pergunta.

A resposta trazia um valor accuracy em metros. O texto de 2013 dizia que a precisão deveria corresponder a um nível de confiança de 95%. Um círculo ao redor do ponto azul contaria melhor a história do que uma agulha cravada com pose de certeza. A Recomendação também não garantia a posição real do dispositivo. Para achar o bairro certo, uma estimativa pode bastar; para afirmar em qual porta alguém está, a mesma estimativa pode ser ousada demais.

A autorização de entrega não encerrava o assunto. O W3C orientou quem recebe a solicitar posição quando necessária, usá-la para a tarefa apresentada, descartá-la ao término salvo permissão expressa para guardar, e não retransmiti-la sem acordo. A busca por uma parada de bonde e um arquivo permanente de deslocamentos podem começar com as mesmas coordenadas. Não são o mesmo serviço.

A Segunda Edição de 2016 incorporou correções à Recomendação de 2013. A divisão central continuou: aparelho e navegador escolhem como estimar; a pessoa decide sobre o primeiro repasse; a aplicação responde pelo uso do dado recebido. O padrão ofereceu uma pergunta comum a mapas, previsão do tempo e guias de viagem, sem ordenar que todos precisassem da mesma precisão ou duração de acompanhamento.

Foi assim que uma rua real entrou na linguagem dos scripts. A página pôde pedir localização sem conhecer cada rádio e cada satélite. A viajante ganhou uma escolha visível antes de entregar a resposta. Pode até continuar segurando o mapa de cabeça para baixo; o navegador ao menos aprendeu a perguntar antes de apontar o caminho.