- Existe uma percepção amplamente difundida de que a plataforma web funciona de forma uniforme sobre APIs padronizadas, mas, na prática, há muitas APIs que dependem de infraestruturas específicas de cada fornecedor de navegador
- Geolocation, Speech, Push, Payments, Passkeys etc. parecem padrões web na superfície, mas internamente chamam serviços do Google, Apple e Microsoft
- Mesmo com a mesma chamada de API, precisão, disponibilidade, incompatibilidades regionais e políticas de privacidade variam bastante entre navegadores, e os desenvolvedores acabam dependendo disso sem perceber
- A estrutura de padronização centrada em grandes fornecedores eleva a barreira de entrada para navegadores menores e para o ecossistema open source, reforçando na prática o efeito de lock-in
- Os desenvolvedores devem entender essas APIs não como “padrões web” puros, mas como uma camada de abstração de serviços do fornecedor, combinando avisos de privacidade, designs alternativos e testes por navegador
Percepção geral sobre a plataforma web e sua estrutura real
- A plataforma web costuma ser vista como um sistema unificado baseado em especificações padronizadas, e espera-se comportamento idêntico entre navegadores com o mesmo motor
- Na prática, muitas APIs dependem de implementações proprietárias de cada navegador e de serviços de terceiros, infraestrutura proprietária e sistemas internos dos fornecedores
- Diferentemente da interface padronizada, os detalhes de implementação variam bastante conforme as escolhas do fornecedor do navegador
Geolocation API e a origem real dos dados de localização
- A Geolocation API fornece uma interface padronizada, mas os dados reais de localização são coletados por vários caminhos
- uso de serviços de localização do sistema operacional e GPS
- estimativa de localização com base em informações de pontos de acesso Wi‑Fi
- consulta a bancos de dados de localização baseados em endereço IP
- O Chrome usa Google Location Services, o Safari usa servidores da Apple e o Firefox, desde 2024, usa serviços do Google
- Ao usar dados de localização, dados do usuário podem ser enviados para servidores de um fornecedor específico, mas isso não fica explícito na interface do navegador
- Se o acesso ao serviço do fornecedor for bloqueado em determinadas regiões, há a possibilidade de a funcionalidade não operar corretamente
Speech Synthesis e a infraestrutura de processamento de voz
- A síntese de fala da Web Speech API usa mecanismos diferentes conforme o navegador, o sistema operacional e o dispositivo
- A Speech Synthesis API é uma interface padronizada, mas os dados de voz são processados por mecanismos TTS do sistema operacional ou por servidores em nuvem
- o Chrome combina processamento local e em nuvem, enquanto o Safari usa o mecanismo de voz do sistema operacional
- algumas vozes de alta qualidade exigem processamento em nuvem, o que requer transmissão online e faz com que dados do usuário sejam enviados ao servidor
- há risco de mensagens pessoais ou informações sensíveis serem enviadas inadvertidamente para servidores externos
- Além disso, a voz escolhida no ambiente de teste pode não existir no ambiente do usuário
Speech Recognition e transmissão de voz em tempo real
- A Speech Recognition API depende, em sua maioria, de serviços de reconhecimento em nuvem
- o Chrome usa Google, o Safari usa Apple e o Edge usa serviços da linha Azure
- desde o Chrome 139, o processamento local é possível com a opção
processLocally, mas não é o padrão, e isso também é um recurso restrito ao Chrome
- precisão e suporte a idiomas variam conforme a qualidade dos modelos de cada fornecedor
Passkeys e a base real do WebAuthn: dependência do ecossistema do navegador
- A WebAuthn API propõe autenticação sem senha, mas, na prática, depende da infraestrutura de gerenciador de senhas do navegador
- o Chrome usa Google Password Manager, o Safari usa iCloud Keychain e o Edge usa Microsoft Account
- o Polypane e outros não oferecem suporte a Passkey devido a limitações do Electron, exigindo o uso de extensões como 1Password
- A forma de armazenamento, sincronização e recuperação das credenciais é determinada inteiramente pela implementação de cada fornecedor
Payment Request API e dependência de fornecedores de pagamento
- A Payment Request API parece um padrão, mas, na prática, o funcionamento do pagamento varia conforme os parceiros do fornecedor
- O Chrome usa Google Pay, o Safari usa Apple Pay, o Edge usa integração da Microsoft e o Firefox não oferece suporte
- Suporte regional, UX e requisitos de configuração adicional para o usuário variam entre navegadores
- Como resultado, são necessários contratos separados e lógica específica de tratamento para cada meio de pagamento
Push API e redes de notificação por fornecedor
- A Push API é um padrão, mas a infraestrutura de servidor usada para entregar notificações difere entre navegadores
- Chrome e Edge usam FCM, o Safari usa APNs e o Firefox usa Mozilla Push Service
- limites de envio, tamanho de mensagem, processamento offline e políticas de privacidade variam conforme o serviço
- Em caso de falha na infraestrutura do fornecedor, toda a funcionalidade de push daquele navegador pode ser afetada
APIs de mídia, codecs e DRM
- Media Source Extensions (MSE) e Encrypted Media Extensions (EME) são padrões, mas o suporte varia conforme licenças de codec e DRM
- Chrome, Edge e Firefox dependem de Widevine, enquanto o Safari usa FairPlay, ou seja, há dependência de tecnologias totalmente proprietárias
- Cada fornecedor de navegador tem codecs e estratégias preferenciais diferentes
- Devido ao custo de licenças DRM e às restrições técnicas, navegadores pequenos têm dificuldade para oferecer suporte
O surgimento de APIs de IA no navegador: uma nova estrutura proprietária
- O Chrome está experimentando APIs de IA baseadas em Gemini Nano (resumo, tradução, revisão etc.)
- Embora a execução local evite transmissão de dados, o tamanho do modelo (cerca de 4 GB) e a exigência de GPU são altos, além de ser um modelo proprietário do Google
- Outros navegadores precisam desenvolver seus próprios modelos, e navegadores menores ou projetos open source não conseguem obter nem manter o mesmo modelo, ficando incapazes de competir
- Isso representa uma nova estrutura de dependência de fornecedor baseada em IA
Por que isso importa
- Problema de portabilidade: mesmo com o mesmo código, a qualidade do funcionamento pode variar conforme navegador, região e ambiente
- Risco de privacidade: dados de voz, localização e push podem ser enviados inadvertidamente para servidores do fornecedor
- Desequilíbrio na padronização: grandes empresas lideram a redação das especificações e a implementação, tornando sua própria infraestrutura praticamente um requisito obrigatório e excluindo navegadores menores
- Impacto para desenvolvedores: os recursos são úteis, mas é preciso reconhecer que existe dependência de serviço, e não apenas de padrão
Abordagem que os desenvolvedores devem adotar
- Encarar a API como uma camada de abstração de serviços do fornecedor e preparar testes, documentação e caminhos alternativos
- Projetar com degradação gradual (graceful degradation) para lidar com divergências de funcionalidade
- Garantir transparência de privacidade: deixar claro que os dados podem ser enviados para servidores de terceiros
- Gerenciar dependências de fornecedor: é necessário ter um plano para interrupções de serviço ou mudanças de política
- Fazer testes por navegador e por região para verificar diferenças de qualidade
- Fazer escolhas estratégicas para minimizar a dependência de fornecedores
A web que imaginamos vs. a web real
- A chamada de API padronizada é a mesma, mas fluxo de dados, precisão, suporte regional, privacidade e estrutura de custos variam entre navegadores
- chamar
navigator.geolocation.getCurrentPosition() equivale, na prática, a chamar os serviços de localização do Google ou da Apple
- A especificação padronizada define apenas a interface, enquanto o funcionamento real depende da infraestrutura e das políticas do fornecedor
- fazer uma chamada de API significa usar os servidores, as políticas e o modelo de negócios de um fornecedor específico
- A plataforma web é poderosa, mas, na prática, tem uma estrutura mais fragmentada e centrada em fornecedores
- Os desenvolvedores precisam projetar entendendo claramente a fronteira entre padrão e implementação
Ainda não há comentários.