- Existe una percepción muy extendida de que la plataforma web funciona de forma uniforme sobre API estandarizadas, pero en la práctica hay muchas API que dependen de infraestructura específica de cada proveedor de navegador
- Geolocation, Speech, Push, Payments, Passkeys y otras parecen estándares web en la superficie, pero internamente llaman a servicios de Google, Apple y Microsoft
- Incluso con la misma llamada de API, la precisión, disponibilidad, incompatibilidades regionales y políticas de privacidad pueden variar mucho entre navegadores, y los desarrolladores terminan dependiendo de ello sin darse cuenta
- La estructura de estandarización centrada en grandes proveedores eleva la barrera de entrada para navegadores pequeños y el ecosistema de código abierto, y refuerza de facto el efecto de bloqueo (lock-in)
- Los desarrolladores deben entender estas API no como “estándares web” puros, sino como una capa de abstracción de servicios del proveedor, y acompañarlas con avisos de privacidad, diseños alternativos y pruebas por navegador
Percepción general de la plataforma web y su estructura real
- La plataforma web suele verse como un sistema unificado basado en especificaciones estándar, y se espera el mismo comportamiento en navegadores basados en el mismo motor
- En la práctica, muchas API dependen de implementaciones propias de cada navegador y de servicios de terceros, infraestructura propietaria y sistemas internos del proveedor
- A diferencia de la interfaz estandarizada, los detalles de implementación pueden variar enormemente según las decisiones del proveedor del navegador
Geolocation API y el origen real de la información de ubicación
- Geolocation API ofrece una interfaz estandarizada, pero la ubicación real se obtiene por distintas vías
- Uso de servicios de ubicación del sistema operativo y GPS
- Estimación de ubicación basada en información de puntos de acceso Wi‑Fi
- Consulta a bases de datos de ubicación basadas en direcciones IP
- Chrome usa Google Location Services, Safari usa servidores de Apple y Firefox, desde 2024, usa servicios de Google
- Al usar información de ubicación, los datos del usuario pueden enviarse a servidores de un proveedor específico, pero la interfaz del navegador no lo muestra de forma explícita
- Si el acceso al servicio del proveedor está bloqueado en ciertas regiones, es posible que la función no opere correctamente
Speech Synthesis e infraestructura de procesamiento de voz
- La síntesis de voz de Web Speech API usa motores distintos según el navegador, el sistema operativo y el dispositivo
- Speech Synthesis API tiene una interfaz estandarizada, pero los datos de voz se procesan en el motor TTS del sistema operativo o en servidores en la nube
- Chrome combina procesamiento local y en la nube, mientras que Safari usa el motor de voz del sistema operativo
- Algunas voces de alta calidad requieren procesamiento en la nube, por lo que necesitan transmisión en línea y los datos del usuario se envían al servidor
- Existe el riesgo de que mensajes personales o información sensible se envíen sin intención a servidores externos
- Además, la voz seleccionada en el entorno de pruebas puede no existir en el entorno real del usuario
Speech Recognition y transmisión de voz en tiempo real
- Speech Recognition API depende en la mayoría de los casos de servicios de reconocimiento en la nube
- Chrome usa Google, Safari usa Apple y Edge usa servicios de la familia Azure
- Desde Chrome 139, la opción
processLocally permite procesamiento local, pero no es el valor predeterminado y además es una función exclusiva de Chrome
- La precisión y el soporte de idiomas varían según la calidad del modelo de cada proveedor
Passkeys y la base real de WebAuthn: dependencia del ecosistema del navegador
- WebAuthn API promueve la autenticación sin contraseña, pero en la práctica depende de la infraestructura del administrador de contraseñas del navegador
- Chrome usa Google Password Manager, Safari usa iCloud Keychain y Edge usa Microsoft Account
- Polypane y otros no admiten Passkeys por limitaciones de Electron, por lo que requieren extensiones como 1Password
- La forma de almacenar, sincronizar y recuperar credenciales depende por completo de la implementación de cada proveedor
Payment Request API y dependencia de proveedores de pago
- Payment Request API parece un estándar, pero en la práctica el funcionamiento del pago depende de los socios del proveedor
- Chrome usa Google Pay, Safari usa Apple Pay, Edge usa integración de Microsoft y Firefox no lo admite
- El soporte por región, la UX y los requisitos de configuración adicional para el usuario difieren entre navegadores
- Como resultado, se necesitan contratos separados y lógica específica de integración para cada medio de pago
Push API y redes de notificación por proveedor
- Push API es un estándar, pero la infraestructura de servidor usada para entregar notificaciones cambia según el navegador
- Chrome/Edge usan FCM, Safari usa APNs y Firefox usa Mozilla Push Service
- Los límites de envío, tamaño de mensaje, procesamiento offline y políticas de privacidad difieren entre servicios
- Una falla en la infraestructura del proveedor puede afectar toda la función de push en ese navegador
API de medios, códecs y DRM
- Media Source Extensions (MSE) y Encrypted Media Extensions (EME) son estándares, pero el soporte cambia según códecs y licencias DRM
- Chrome, Edge y Firefox usan Widevine, mientras que Safari usa FairPlay, por lo que dependen de tecnologías totalmente propietarias
- Cada proveedor de navegador tiene códecs preferidos y estrategias distintas
- Por costos de licencias DRM y limitaciones técnicas, los navegadores pequeños tienen dificultades para ofrecer soporte
La aparición de API de IA dentro del navegador: una nueva estructura propietaria
- Chrome está experimentando con API de IA basadas en Gemini Nano (resumen, traducción, corrección, etc.)
- Aunque se ejecutan localmente y no hay envío de datos, el tamaño del modelo (aprox. 4 GB) y los requisitos de GPU son altos, además de tratarse de un modelo propietario de Google
- Otros navegadores tendrían que desarrollar sus propios modelos, y navegadores pequeños o proyectos de código abierto no pueden conseguir ni mantener un modelo equivalente, por lo que no pueden competir
- Esto crea una nueva estructura de dependencia del proveedor basada en IA
Por qué importa
- Problemas de portabilidad: incluso con el mismo código, la calidad del funcionamiento puede cambiar según el navegador, la región y el entorno
- Riesgos de privacidad: datos de voz, ubicación y push pueden enviarse sin intención a servidores del proveedor
- Desequilibrio en la estandarización: grandes empresas lideran la redacción de especificaciones y la implementación, y convierten su infraestructura en una condición de facto obligatoria, dejando fuera a navegadores pequeños
- Impacto en desarrolladores: la funcionalidad es útil, pero hay que reconocer que existe dependencia de servicios, no solo de estándares
Enfoque que deberían adoptar los desarrolladores
- Entender las API como una capa de abstracción de servicios del proveedor y preparar pruebas, documentación y rutas alternativas
- Diseñar con degradación progresiva (graceful degradation) para anticipar discrepancias funcionales
- Asegurar transparencia en privacidad: dejar claro que los datos podrían enviarse a servidores de terceros
- Gestionar la dependencia del proveedor: hacen falta planes de respuesta ante interrupciones del servicio o cambios de política
- Realizar pruebas por navegador y región para verificar diferencias de calidad
- Minimizar la dependencia del proveedor mediante decisiones estratégicas
La web que creemos que existe vs. la web real
- Las llamadas a API estandarizadas son las mismas, pero el flujo de datos, la precisión, el soporte regional, la privacidad y la estructura de costos cambian según el navegador
- Llamar a
navigator.geolocation.getCurrentPosition() equivale en la práctica a llamar a servicios de ubicación de Google o Apple
- La especificación estándar solo define la interfaz, mientras que el comportamiento real depende de la infraestructura y las políticas del proveedor
- Llamar una API implica usar los servidores, políticas y modelo de negocio de un proveedor específico
- La plataforma web es poderosa, pero en la práctica es más fragmentada y más centrada en proveedores de lo que parece
- Los desarrolladores deben diseñar entendiendo con claridad la frontera entre estándar e implementación
Aún no hay comentarios.