Inclinación de la plataforma

 (mozilla.github.io)
1 puntos por GN⁺ 2024-01-21 | 1 comentarios | Compartir por WhatsApp
  • Platform Tilt de Mozilla rastrea las condiciones técnicas en las principales plataformas de software que ponen a Firefox en desventaja frente al navegador propio de la plataforma, y deja en evidencia brechas competitivas en seguridad, estabilidad, rendimiento y funciones
  • Los problemas relacionados con Apple son los más extendidos: prohibición de motores de navegador de terceros, restricciones de iOS sobre multiproceso, JIT y API de accesibilidad, configuración del navegador predeterminado, distribución de extensiones y betas, y hasta el manejo de web apps en la pantalla de inicio
  • En Google Android, los puntos clave son la ausencia de una API para importar datos del navegador, flujos en los que las apps de Google abren Chrome en vez del navegador predeterminado, y casos en los que se entregaron páginas de resultados de búsqueda de baja calidad a Firefox para Android
  • En Microsoft Windows, a los navegadores de terceros les resulta difícil establecerse programáticamente como navegador predeterminado, y flujos como Search, Copilot y Widgets priorizan Edge
  • En común, la elección del navegador predeterminado por parte del usuario, el traslado de datos entre navegadores, las funciones del motor y la accesibilidad para distribución, pruebas y extensiones operan en cada plataforma a favor del navegador propio

Lo que rastrea Platform Tilt

  • Platform Tilt es un panel que rastrea casos técnicos en los que Firefox queda en desventaja frente al navegador principal en las principales plataformas de software
  • Se enfoca en seguridad, estabilidad, rendimiento y funciones, y propone cambios para crear un entorno competitivo más equilibrado
  • La discusión de problemas en tiempo real se lleva a cabo en el platform-tilt issue tracker

Restricciones del motor de navegador y de funciones de iOS en la plataforma Apple

  • App Store forbids third-party browser engines: la Rule 2.5.6 de las Apple App Store Review Guidelines exige que las apps de navegación web usen el framework WebKit adecuado y JavaScript de WebKit
    • Debido a esta política, Firefox no puede distribuirse con Gecko en iOS
    • También afecta la distribución de Firefox a través de la App Store en otras plataformas de Apple, como macOS
    • La política de la App Store debería cambiar para permitir motores de navegador de terceros en los navegadores web
  • Support for third-party multi-process applications on iOS: los navegadores web modernos usan una arquitectura multiproceso que incluye procesos por sitio y procesos dedicados para funciones sensibles como la GPU
    • Safari usa una estructura multiproceso en iOS, pero ese mismo mecanismo no está disponible para apps de terceros que no usan el motor WebKit de Safari
    • iOS debería ofrecer mecanismos para crear procesos hijo aislados y comunicarse con ellos de forma eficiente
    • Los requisitos incluyen la cantidad y vida útil de los procesos hijo según el comportamiento de navegación del usuario, configuración de permisos restringidos, mensajería y memoria compartida, regiones de memoria compartida de lectura/escritura o solo lectura, entitlements independientes para procesos padre e hijo, carga de bibliotecas dentro del bundle, y renderizado de IOSurface mediante Metal u OpenGL y su uso compartido entre procesos
    • Como Firefox usa una base de código compartida en varios sistemas operativos, la interfaz y el comportamiento de la gestión de procesos deberían ser en general similares a otras plataformas como macOS y Android
  • JIT Support on iOS: para distribuir un motor de JavaScript/WebAssembly de alto rendimiento, el proceso del navegador debe poder crear regiones de memoria que sean escribibles y ejecutables
    • Las apps de iOS no pueden crear esos permisos de memoria con la llamada al sistema mmap(2)
    • El motor de renderizado WebKit de Safari tiene una excepción y sí puede crear regiones de memoria escribibles y ejecutables
    • En macOS existe un mecanismo correspondiente al entitlement de Hardened Runtime com.apple.security.cs.allow-jit, y iOS también debería ofrecer a los navegadores no WebKit un entitlement equivalente y permiso para usar las API pthread_jit_write_protect_np y sys_icache_invalidate
  • Accessibility APIs on iOS: la documentación de las API de accesibilidad de iOS está incompleta, y muchas API que necesita un navegador web para soportar estándares web de accesibilidad no están documentadas
    • Parece que WebKit incluye un bundle del sistema de código cerrado que se carga en tiempo de ejecución, lo que dificulta incluso inferir cómo se usa
    • Algunas constantes enteras de traits como “visited” y “radio button”, y constantes enteras de tipos de notificación como “value changed”, no son públicas
    • Todas las API de accesibilidad que usa WebKit deberían estar documentadas y ser estables, e idealmente WebKit también debería usarlas de la misma manera que los motores de navegador de terceros

Brechas de experiencia de usuario, distribución y expansión en la plataforma de Apple

  • Messages integration on iOS: la página de inicio de Safari en iOS muestra enlaces recibidos recientemente y contactos enviados en la app Messages, pero los navegadores de terceros no pueden ofrecer la misma función porque no tienen permiso para acceder a los datos de Messages

  • Importing browser data on iOS: en iOS, los navegadores de terceros no pueden acceder a datos de navegación como historial, marcadores y cookies, y tampoco existe una API de importación

    • Estos datos son sensibles, pero en las principales plataformas de escritorio sí se permiten funciones de importación similares
    • iOS podría mediar el acceso a datos sensibles con consentimiento del usuario, como hace con los datos de salud y fitness
    • Si no es posible importar datos, se genera fricción al cambiar de Safari a otro navegador

  • Setting and checking default browser on iOS: iOS no ofrece a los navegadores de terceros una función para mostrar un aviso del sistema que solicite establecerse como navegador predeterminado

    • Android ofrece una función similar mediante la solicitud de browser role, y macOS mediante LSSetDefaultHandlerForURLScheme y LSSetDefaultRoleHandlerForContentType
    • Los navegadores en iOS solo pueden hacer deep link a la interfaz de configuración, y el usuario debe entender esa pantalla y realizar el cambio manualmente
    • Hay casos en iOS 17.2.1 donde al escribir “Default browser app” o “Default” en la búsqueda de Settings no aparece el resultado para cambiar el navegador predeterminado
    • Los navegadores de terceros tampoco pueden detectar si actualmente son el navegador predeterminado, por lo que es difícil optimizar el navegador según la intención del usuario o pedir el cambio en el momento adecuado

  • Origin-Based Associated Domains dependent features for third-party browser engines on iOS: para que los navegadores que no usan WebKit admitan password autofill, one-time codes, passkeys y Apple Pay, deben poder especificar associated domain basados en el origin del contenido web

    • Los navegadores basados en WebKit pueden sobrescribir el associated domain de la app del navegador con el dominio que el usuario está visitando
    • Por ejemplo, en un campo de contraseña de example.com, el navegador debe indicar que ese campo pertenece al origin de example.com para que el gestor de contraseñas se invoque dentro del alcance de example.com
    • Para admitir Apple Pay, podrían requerirse cambios adicionales para que, como en Safari, se puedan recibir pagos para beneficiarios de Apple Pay registrados

  • Browser extension support on iOS: Safari admite extensiones distribuidas a través del App Store de iOS, pero a los navegadores de terceros les resulta difícil ofrecer sus propias extensiones debido a la guideline 2.5.2 de App Store Review

    • Las extensiones de navegador son un elemento clave del ecosistema web y permiten que los desarrolladores agreguen funciones al navegador para mejorar la utilidad, la usabilidad y la interoperabilidad con apps del sistema
    • Deberían flexibilizarse los requisitos de software del App Store para que los navegadores de terceros puedan usar sus propios catálogos de extensiones

  • Beta testing on iOS: en iOS no es posible distribuir versiones beta de apps en el App Store y se debe usar TestFlight

    • TestFlight tiene un límite de 10,000 personas, una cifra pequeña frente al tamaño de la base de usuarios beta de navegadores a gran escala
    • Cuando se alcanza el límite, hay que eliminar manualmente a usuarios antiguos, lo que añade carga de mantenimiento
    • Los usuarios deben pasar por el proceso de instalar la app de TestFlight, solicitar un access code, esperar, e ingresar el código
    • Las nuevas versiones de Safari vienen incluidas en las betas del sistema operativo iOS y no están sujetas a la misma limitación
    • Como solución, se propone permitir la distribución de builds preliminares de navegadores en el App Store, o eliminar el límite de usuarios de TestFlight y permitir distribución ilimitada mediante enlaces públicos

  • iOS and macOS "Search Web" features open links in Safari instead of the user’s default browser: las opciones de menú contextual Search Web o Search with <Search Engine> en iOS y macOS, así como los puntos de entrada de búsqueda de Services en la barra de menú de macOS, realizan la búsqueda en Safari sin importar cuál sea el navegador predeterminado del usuario

  • SFSafariViewController should respect the user’s default browser: SFSafariViewController es una API de alto nivel que permite a las apps de iOS incrustar contenido web dentro de la app mientras delegan el renderizado al navegador del usuario

    • Esta API siempre usa la versión de Safari, sin importar cuál sea el navegador predeterminado del usuario
    • La experiencia de visualización de contenido web se vuelve inconsistente y el tráfico se desvía de los navegadores alternativos

  • Browsers with alternative engines should be able to ship a single binary & bundle on iOS: la propuesta actual de Apple exige que los proveedores de navegadores que quieran usar su propio motor distribuyan una app separada en la UE, en lugar de actualizar la app existente

    • Los usuarios actuales de la UE tendrían que migrar a la nueva app, lo que tiene baja viabilidad y crea una barrera competitiva
    • Entre los casos de preocupación de Firefox están la dificultad para descubrir y migrar de Firefox con WebKit a Firefox con Gecko, la pérdida de acceso de usuarios de Firefox con Gecko en la UE cuando permanecen fuera de la UE durante más de 30 días, y el caso de usuarios no UE de Firefox con WebKit que se mudan permanentemente a la UE y quedan en una versión “huérfana” que ya no recibe actualizaciones
    • Los desarrolladores de navegadores tendrían que desarrollar, mantener y distribuir dos apps completamente separadas, lo que genera complejidad en la migración de datos, abandono de usuarios, menor adquisición y limitaciones para despliegues iterativos de A/B dirigidos a usuarios de iOS en la UE
    • Como alternativa, se propone incluir los webviews de ambos motores en un único binario y bundle global, y que el sistema operativo informe a la app al iniciarse sobre la elegibilidad de BrowserEngineKit

  • Los desarrolladores web deberían poder probar con motores de navegador alternativos en iOS sin importar su ubicación: Cuando se anunció por primera vez, BrowserEngineKit tenía una restricción geográfica que impedía probar motores propios en dispositivos fuera de la UE

    • Esta restricción se eliminó en la beta 18.2 para el desarrollo y las pruebas locales, pero sigue vigente para los desarrolladores web
    • Los desarrolladores web fuera de la UE también pueden dar soporte a usuarios de la UE, por lo que se necesita un mecanismo para probar fácilmente sitios en motores de navegador alternativos sin importar la ubicación

  • Los navegadores con motores alternativos deberían poder instalar y administrar apps web en la pantalla de inicio en iOS: Hay una API que permite que los motores de navegador alternativos agreguen apps web a la pantalla de inicio de iOS, pero esas apps se abren en Safari

    • Antes y después de la instalación, las funciones por motor, el estado del usuario y las preferencias cambian, lo que fragmenta la experiencia
    • Apple se ha opuesto a permitir el renderizado de apps web en la pantalla de inicio con motores que no sean WebKit por motivos de seguridad
    • Los requisitos básicos de seguridad para las apps web en la pantalla de inicio son los mismos que los requisitos de sandboxing y aislamiento entre sitios que ya se aplican en la navegación web normal
    • Android ha delegado durante años el renderizado de apps web a motores de navegador de terceros, y esto también debería habilitarse en iOS

Transferencia de datos, navegador predeterminado y experiencia de búsqueda en Google Android

  • Importing browser data on Android: en Android, los datos de navegación como historial, marcadores y cookies no son accesibles para navegadores de terceros
    • Los datos se almacenan en el data directory de la app del navegador web, y los navegadores de terceros no pueden acceder directamente a ellos
    • Tampoco existe una API ni un ContentProvider que permita la importación
    • La falta de importación de datos genera una gran fricción al cambiar de Chrome a otro navegador
  • Some Android features launch Chrome instead of the user’s default browser: funciones de Google application preinstaladas, como Google Search y Discover, ignoran la elección del navegador predeterminado del usuario y siempre abren los enlaces de sitios web externos en Chrome
    • También hay puntos de entrada adicionales en funciones integradas como la barra de búsqueda de la pantalla de inicio y el lanzador de aplicaciones
    • Cada vez que un enlace se abre en Chrome, el usuario se desvía de su navegador predeterminado
    • Todas las apps y funciones integradas que abren enlaces externos deberían hacerlo en el navegador predeterminado del usuario
  • Lower quality search result pages in third-party browser engines on Android: en Android, la experiencia de búsqueda web está estrechamente integrada con varias funciones del sistema, y ha habido casos en los que Firefox recibió páginas de resultados de búsqueda de menor calidad que Chrome
    • Para la misma búsqueda, Firefox Android recibió una página con menos información y con una calidad de diseño inferior a la de Chrome
    • Aunque estrictamente se trata de un problema del sitio web de Google Search, por la importancia y el nivel de integración de la búsqueda en Android esto termina generando una brecha de experiencia de usuario que desincentiva elegir navegadores de terceros
    • No existe una limitación técnica que impida que esa página funcione en Firefox
    • El estado de este problema es closed

Flujos de Windows de Microsoft que priorizan Edge

  • Setting default browser on Windows: Windows no ofrece una forma para que los navegadores de terceros soliciten por programación ser configurados como navegador predeterminado
    • Incluso después de instalar un navegador, el usuario debe ir manualmente a la configuración del sistema operativo y elegirlo, lo que genera fricción e inercia a favor de seguir usando Edge
    • Android y macOS ofrecen patrones mediante avisos del sistema o APIs relacionadas para que el usuario pueda aprobar o rechazar fácilmente
    • En Windows 10, la UI de configuración exige varios clics y una doble confirmación, y aunque en Windows 11 existe un botón Set default, no es suficiente
  • Default browser is set to Edge by several Windows flows: Windows 10 y 11 muestran de forma continua mensajes de que Microsoft Edge es el navegador “recommended” de Windows y ofrecen UI para cambiar el navegador predeterminado a Edge
    • Algunos textos preguntan si se desea aplicar “recommended browser settings”, sin dejar claro que eso cambia el navegador predeterminado
    • Los ejemplos se agregan y eliminan en distintas superficies de UI que aparecen automáticamente, como Windows Update, y siguen cambiando
    • Los componentes de Windows pueden cambiar directamente el navegador predeterminado del usuario, pero los navegadores de terceros deben usar deep links del protocolo ms-settings:
    • Windows también debería usar las mismas funciones y APIs que se ofrecen a los navegadores de terceros
  • Some Windows features launch Edge instead of the user’s default browser: al menos tres funciones principales de Windows abren URL en Microsoft Edge en lugar de hacerlo en el navegador predeterminado actual
    • Windows Search o Start Menu Search aparece mediante el cuadro de búsqueda de la barra de tareas, el botón de búsqueda, la escritura en el menú Inicio o el atajo WIN+S, y tanto los resultados de búsqueda como los enlaces de artículos se abren en Edge
    • Windows Copilot aparece en Windows 11 como una ventana acoplada al lado derecho de la pantalla, y abre en Edge los enlaces de las respuestas o del área renderizada
    • Widgets se llamaba “news and interests” en Windows 10, muestra información como noticias, clima, acciones y resultados deportivos, y abre en Edge los enlaces a páginas web

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-01-21
Comentarios de Hacker News

  • Dicen que tanto Android como Microsoft tienen apps que abren enlaces a su manera en lugar de usar el navegador elegido por el usuario, pero el problema mayor es que, al pulsar un enlace dentro de una app, se abra una webview integrada como si fuera un navegador.
    La app puede vigilar la actividad web que hagas ahí dentro. Ojalá Google Play Store y iOS App Store obligaran a que todos los sitios web de terceros se abran en el navegador del usuario.
    Se podría clasificar las apps como “navegador web” y “no navegador web”, y exigir que las apps “no navegador web” registren solo una lista corta de 5 a 10 dominios accesibles, mientras que el sistema operativo bloquee el resto.
    Apps como Facebook, FB Messenger o Google Maps, cuyo propósito principal no es navegar por la web, claramente podrían considerarse “no navegador web”.
    Así se evitaría el problema de vigilancia de las webviews integradas y se podrían usar tal cual las contraseñas, direcciones, marcadores e historial sincronizados en el perfil del navegador. Si pudiera decidir cómo funciona el mundo, también exigiría que las apps que abren enlaces incluyan una opción en el menú contextual de “Abrir en una ventana privada del navegador”.

    • En lo personal pienso igual, pero hace poco descubrí que la mayoría de los usuarios no. Cuando lanzamos la app de autotempest, hicimos que todos los enlaces de terceros que llevaban directamente a páginas de detalle de vehículos en varios sitios se abrieran en el navegador predeterminado del usuario, pero a los usuarios no les gustó y querían con fuerza que se abrieran dentro de la app.
      Así que cambiamos el valor predeterminado para abrirlos dentro de la app, aunque dejamos la opción de usar el navegador predeterminado.
    • Resolver el problema del navegador dentro de la app es una de las máximas prioridades de Open Web Advocacy. Pero se complica por lo que sí se puede hacer dentro del alcance de la Digital Markets Act.
      Estoy de acuerdo en que es un tema realmente importante, y si quieres ayudar, por favor contacta a Open Web Advocacy.
    • Google, de hecho, empujó a los desarrolladores de Android justo en la dirección contraria al crear la función de Custom Tabs.
      Recomienda que las apps abran en una “custom tab”, en vez del navegador predeterminado, incluso páginas no relacionadas, por ejemplo enlaces proporcionados por el usuario; el objetivo explícito es que el usuario no salga de la app para mantener su nivel de interacción.
      Por supuesto, no hay ninguna opción a nivel del sistema para desactivarlo; hay que buscar la configuración app por app, y eso suponiendo que exista.
      https://android-developers.googleblog.com/2023/02/bringing-b...
    • En cierto grado ya es posible, porque se puede pulsar “Abrir en el navegador”. Pero no sé si eso realmente va en línea con los intereses de Google.
      Han pasado 9 generaciones de versiones principales desde que Android añadió permisos en tiempo de ejecución para cosas como la cámara, pero el acceso a internet todavía no requiere permiso.
    • Me parece que la idea de los puntos 2 a 4, “aislar en sandbox el contexto de la webview para que no se mezcle con la actividad real de navegación web ni con las webviews de otras apps”, entra en conflicto con el punto 1, “es peligroso porque la app puede controlar su propia webview”.
      Tampoco queda claro qué significa exactamente “dominios accesibles”. Si solo se revisa el dominio de la URL a la que se navegó explícitamente, sería demasiado permisivo y fácil de evadir; si se revisan todas las URL de las solicitudes, sería demasiado estricto y muchos desarrolladores ni siquiera podrían cargar bien sus propios sitios.

  • Que Mozilla cuestione que “la App Store prohíbe motores de navegador de terceros” es válido, pero no sé si quiera tirar de ese hilo
    Como en los dispositivos iOS existe el monopolio de Safari, bastantes desarrolladores se preocupan por dar soporte a navegadores que no sean Chrome. Ahora mismo tienen que hacerlo a la fuerza
    Si a los usuarios les empieza a llegar el mensaje de “la función rota no se rompe en Chrome”, eso es el camino hacia un monopolio, y después Google ya no necesitará mucho consenso cuando cree nuevos estándares web
    La situación actual ya es un desastre, pero todavía podría empeorar. Ojalá esta predicción esté equivocada

    • Desafiar el monopolio de Safari que Apple impone en iOS obviamente va en línea con los intereses de Mozilla. Que Chrome también esté limitado en iOS no hace que limitar a Firefox beneficie a Firefox
      Si desaparecen las restricciones de Apple que impiden a Firefox implementar Gecko y WebExtensions basadas en Gecko, en especial los bloqueadores de anuncios, la cuota de Firefox en iOS inevitablemente subiría
      Esos nuevos usuarios de Firefox en iOS podrían sincronizarse con Firefox de escritorio y con Firefox en iOS con bloqueo de anuncios, lo que también podría empujarlos a usar Firefox en escritorio
    • Vine a decir lo mismo. Que en iOS no se pueda reemplazar Safari por Chrome es, para bien o para mal, la única barrera que evita el dominio total de Chrome
    • Si hubiera libre competencia en iOS, creo que mucha gente instalaría Chrome. En especial, probablemente la mayoría de los usuarios de PC cuyo único dispositivo Apple es el iPhone
    • La razón por la que hago que mi sitio web funcione en Firefox no es para que también funcione en Safari
      Firefox normalmente simplemente funciona, y aunque no fuera así, no me dan ganas de preocuparme también por otra pila tecnológica más por culpa de Safari, que siempre necesita trabajo extra y es una plataforma descuidada
    • Si Mozilla no señala a Apple, sus quejas sobre otras empresas también pueden ser desestimadas usando Safari como excusa. Como Mozilla tiene razón sobre la conducta de Apple, criticar a Google/Microsoft pero dejar fuera a Apple se vería hipócrita
      Estoy cansado de los argumentos que defienden el estado actual. Mantener las cosas como están no va en una buena dirección y no va a cambiar sin medidas drásticas. Incluso quienes defienden el statu quo de Apple no parecen tener un plan de cómo mejorará esto en adelante
      Safari por sí solo no basta para frenar el dominio de Chrome, y después de que entren en vigor las reglas de la App Store de la UE, tampoco está garantizado a largo plazo que el statu quo se mantenga, porque no es nada improbable que se fuerce la apertura de los motores de navegador
      Ahora mismo se está terminando una administración de EE. UU. que históricamente mostró una fuerte voluntad de hacer cumplir las leyes antimonopolio contra las tecnológicas. Mucha gente no entiende lo favorable que es la administración Biden hacia la agenda antimonopolio
      Esta administración podría durar cuatro años más o no, pero dada esa incertidumbre, este es uno de los mejores momentos desde el primer caso antimonopolio de Windows para exigir una intervención real sobre Google/Apple/Microsoft
      Con una administración abierta al antimonopolio, un cambio en el sentimiento del consumidor hacia Big Tech, la presión de Apple alrededor de iOS y el intento de Google en junio de debilitar los bloqueadores de anuncios, ahora es un buen momento para impulsar con fuerza un cambio del estado actual
      No está exento de riesgos, pero esperar más no va a mejorar la situación. Cuanto más se espere, menos relevancia tendrá Firefox, mayor será la probabilidad de que cambie la administración y más difícil será para Mozilla aprovechar la opinión pública
      Nunca llegará un momento en que Mozilla pueda ganar este argumento de forma fácil al 100%, y si no actúa ahora, al final quedará completamente desplazada del mercado
      Apoyo que señale el problema con toda la fuerza posible contra todos, incluido Apple. Si preocupa el dominio de Chrome después de abrir iOS, ese problema hay que tratarlo regulando a Google, y ahora es el mejor momento para hacer ese argumento

  • Como usuario de Android, la razón principal por la que no uso Firefox no son las prácticas anticompetitivas, sino que se siente lento
    En Firefox pasa seguido que el diseño se reacomoda al cargar la página de inicio, la animación del teclado a veces se traba y no se puede usar la opción del menú “soltar para seleccionar”

    • Llevo años usándolo y nunca he notado esa diferencia
    • ¿Qué es “soltar para seleccionar”?
    • En Firefox tampoco funcionan en absoluto los atajos predeterminados de navegación con teclado de un teclado externo

  • https://github.com/mozilla/platform-tilt/issues/3
    El soporte de JIT en iOS es un factor del que se ha hablado demasiado poco en el debate sobre “la UE obligará motores de renderizado de terceros en iOS”
    ¿Apple permitirá soporte JIT para las apps? ¿Creará un nuevo permiso que los desarrolladores de navegadores tengan que solicitar? Es interesante, pero no parece probable

  • Artículo relacionado: https://blog.mozilla.org/netpolicy/2024/01/19/platform-tilt/
    Llegué desde https://news.ycombinator.com/item?id=39059255, pero ahí no hay comentarios

  • En macOS, si haces clic derecho sobre una selección y eliges buscar en la web, siempre se abre Safari aunque tengas otro navegador configurado como predeterminado. Quizá solo pase en Mail.app, pero parece que omitieron ese punto

  • La mayor queja sobre Firefox para Android es que a veces escribes un dominio en la barra de direcciones y presionas Enter, y no pasa absolutamente nada
    Este comportamiento es irregular y solo afecta a algunos sitios web, como https://forum.syncthing.net
    No se soluciona cerrando la pestaña ni usando otra, y hay que forzar el cierre de la app para arreglarlo

    • El mismo problema existe en escritorio. Parece que hicieron un cambio que en la práctica no modifica casi nada en la barra de direcciones y hasta lo presumieron en una entrada de blog, pero en el proceso crearon una condición de carrera asíncrona y al parecer la han dejado rota durante años
      Aunque tenga quejas, sigue siendo mejor que el navegador de Google
    • A mí también me pasa. Es muy molesto. A veces también falla al azar, y eso empezó hace como un mes

  • Entiendo la mayor parte, pero el punto sobre la integración con Messages en iOS no me da buena espina
    Si fuera algo como una API de “enlaces enviados recientemente” que el usuario tenga que elegir, no habría problema, pero no querría que una app de terceros tuviera acceso a todos los datos de mensajes, aunque Mozilla sea el desarrollador
    En el caso de las extensiones de iOS, Orion puede instalar extensiones tanto de la galería de Chrome como de la de Firefox, así que parece que esto no es un problema real o que ha seguido pasando App Review durante años

  • En Google Colab, copiar y pegar funciona bien en Chrome, pero no en Firefox

  • Dicen que “la información de navegación como historial, sitios marcados y cookies no es accesible para navegadores de terceros en Android”, pero desde la perspectiva del usuario, ¿por qué querría que una aplicación de terceros acceda al historial, marcadores y cookies de mi navegador?
    Eso es claramente una filtración de privacidad. Firefox solo debería tomar los datos que Firefox generó mientras yo usaba Firefox, no datos de otros contextos

    • Solo es una filtración si accede sin permiso. Mientras el usuario pueda responder “de ninguna manera”, no hay problema en que la app pueda solicitar acceso a esos datos
    • Como usuario que quiere cambiarse fácilmente a un navegador nuevo, sí me gustaría que el nuevo navegador pudiera acceder a los marcadores y otros datos del navegador anterior para facilitar el proceso
    • Principalmente sirve para importar/exportar con otros navegadores. Es una tarea muy común durante el onboarding
    • Sin duda me opondría al historial y a las cookies, pero exportar marcadores y volver a importarlos es indispensable
      Sin embargo, Firefox para Android ni siquiera admite eso :facepalm:
      https://github.com/mozilla-mobile/fenix/issues/417
    • Me parece una interpretación algo poco honesta. Los contactos y otros datos sensibles ya se pueden importar sin que eso implique una “filtración de privacidad”
      Incluso en ese issue no se está pidiendo una función de importación sin validar, sino que Android puede mediar el acceso a otros datos sensibles con el consentimiento del usuario)